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