Ask Your Question

Replacing wrapper ROS package for external library - best practices?

asked 2011-07-20 04:50:36 -0500

AHornung gravatar image

updated 2014-01-28 17:10:04 -0500

ngrennan gravatar image

Seeing as more and more "wrapper" packages such as OpenCV are moving away from package dependencies to system dependencies, what is the best practice to transform a low-dependency external library (in this case OctoMap) that is wrapped in a ROS package (octomap) into a working stand-alone package (that is also built within the ROS release chain)?

I was already considering to merge the original source tree (ROS-independent) and ROS package into one source tree, but don't see the need for a dedicated ROS integration if plain CMake also works (and creates less maintenance overhead). This combined ROS / non-ROS build system was previously discussed on ROS users, maybe we can continue that and find a minimal-overhead best practice? (possibly a discussion on ROS users would also be more suited than Answers).

OctoMap already provides an install target, I assume a FindOctoMap CMakeModule is also needed. What else, particularly to build and release the package in ROS?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2011-07-20 05:06:05 -0500

tfoote gravatar image

The removal of the ROS wrapper also takes the package outside of the ROS release system and it makes it a system dependency which we use rosdep to resolve.

Right now on Ubuntu systems we are making sure that we provide deb packages. This is required to be able to automatically build the debian packages for the ROS packages. On other platforms they use source rosdeps or natively packaged packages for those platforms too.

And to be easily used in the ROS build you do need to provide a proper Find* CMakeModule installed with the library.

edit flag offensive delete link more


So, what would be the suggested "best practice" solution? Should wrapper packages be turned into rosdeps, and how could they be built within the ROS release system? Or should they be turned into an unary stack instead, with CMake switches to differentiate between ROS / non-ROS builds?
AHornung gravatar image AHornung  ( 2011-07-20 20:23:07 -0500 )edit
For reference: We've started a wiki page to collect this type of information
tfoote gravatar image tfoote  ( 2011-07-22 11:55:24 -0500 )edit
The optimal option would be to release the package upstream into the debian, fedora, repos. At the moment we have started staging these into our own repo as we seek to push them upstream. If you want to remain inside the ROS Release/Build system a unary stack is the way to go.
tfoote gravatar image tfoote  ( 2011-07-22 11:56:53 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2011-07-20 04:50:36 -0500

Seen: 791 times

Last updated: Jul 20 '11