0
$\begingroup$

Rosanswers logo

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?


Originally posted by AHornung on ROS Answers with karma: 5904 on 2011-07-20

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by tfoote with karma: 58457 on 2011-07-20

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by tfoote on 2011-07-22:
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.

Comment by tfoote on 2011-07-22:
For reference: We've started a wiki page to collect this type of information http://www.ros.org/wiki/BestPractices

Comment by AHornung on 2011-07-20:
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?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.