Hi all,
thanks for all the feedback!
> This is an interesting case. To date, we've brought in non-ROS
> libraries via shell packages that download the source for one of two
> reasons:
> * we don't control the external repo (e.g., Eigen, GMapping); or
> * we do control the external repo, but prefer not to put anything
> ROS-specific in it (e.g., Gazebo, Stage, OpenCV).
>
> In your case, you control the external repo, and are happy to put ROS
> "bindings" in it. I can see the argument for putting the ROS packages
> in the octomap repo. But I think that, at least for now, it would be
> better to keep them separate (i.e., put the ROS packages in your alufr
> repo).
>
> The reason is that our tools assume that the top-level directories of
> a ROS repo are all either stacks or packages. As it's currently
> organized, the octomap code lives outside of any package or stack.
That makes sense, because here the 2nd case applies, at least for the
core functionality. And I guess what works for OpenCV (i.e. is the
ROS-supported way to do it) will work for us too!
So, I would just have a look at the "opencv2" ROS-Makefile and manifest
and adjust that accordingly? Or is there a Tutorial (that goes beyond
http://www.ros.org/wiki/mk#A3rdparty_code.2C_from_SVN) for this
"wrapping" available?
How do people usually deal with $SVN_REVISION, adjust it in the wrapping
ROS package for every "stable" release of the lib?
> Another option would be to simply add the manifest to octmap/trunk to make
> it a proper ROS package itself and put the octmap_server package into
> alufr-ros-pkg. This is an unobtrusive way to convert the existing source.
> And it keeps the octomap package clean of ROS specific stuff, except the
> manifest which all other systems will ignore.
I didn't think of that, that sounds like a nice solution. But couldn't
that create more problems then, since the remaining source structure is
not usual for ROS packages (own CMake-based build, CMakeLists in "src",
.cpp and .h in "src" ...). With octomap_server in alufr-ros-pkg, people
wouldn't get around performing two checkouts anyways, it seems ;)
For the future, maybe there could be a standard ROS solution for
libraries like this, where you could incorporate a ROS binding or
interface into the existing source tree...
Cheers,
Armin
--
Armin Hornung Albert-Ludwigs-Universität
www.informatik.uni-freiburg.de/~hornunga Dept. of Computer Science
HornungA@informatik.uni-freiburg.de Humanoid Robots Lab
Tel.: +49 (0)761-203-8010 Georges-Köhler-Allee 79
Fax : +49 (0)761-203-8007 D-79110 Freiburg, Germany
(text/plain)