Replacing wrapper ROS package for external library - best practices?

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

AHornung

5904 ●43 ●74 ●102 http://www.informatik....

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

ngrennan
1 ●1 ●1

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?

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

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

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

Comments

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 ( 2011-07-20 20:23:07 -0600 )edit

For reference: We've started a wiki page to collect this type of information http://www.ros.org/wiki/BestPractices

tfoote ( 2011-07-22 11:55:24 -0600 )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 ( 2011-07-22 11:56:53 -0600 )edit

add a comment

Replacing wrapper ROS package for external library - best practices?

1 Answer

Comments

Question Tools

Stats

Related questions

Replacing wrapper ROS package for external library - best practices? edit

1 Answer

Comments

Question Tools

Stats

Related questions

Replacing wrapper ROS package for external library - best practices?