Cool!

We have no issues with pointing to small repos. It would be nice to
reorganize the repo a bit so that people can check out the ROS portion
directly into their tree (right now they have to checkout from trunk/
for the Makefile to work, which means they have to set
ROS_PACKAGE_PATH to a sub-portion of the checkout). You might also
want to consider turning the 'ros' directory into an 'octomap_ros'
stack as there are two packages in it.

Our experience with our distributed build system is that 1 SF repo is
flaky, two SF repos are very flaky, so mounting octomap inside of
alufr-ros-pkg would probably make it unpleasant to use.

Hope this helps,
Ken

On Fri, Apr 23, 2010 at 1:56 AM, Armin Hornung
<HornungA@informatik.uni-freiburg.de> wrote:
> Hi!
>
> I was wondering what the right "ROS way" would be to include an
> opensource library (complete with Doxygen documentation) into ROS. With
> my colleagues, we developed a 3D mapping framework based on octrees
> (http://octomap.sf.net/, will be presented at the BRICS workshop at
> ICRA) which is available under GPL in its own Sourceforge repository.
>
> In the source tree (see
> http://octomap.svn.sourceforge.net/viewvc/octomap/trunk/), there's a
> "ros" directory which can be added to the ROS_PACKAGE_PATH. In there,
> there's a sort of "virtual" octomap package that provides the flags for
> linker and compiler. That all works nice and the library can be used in
> other ROS nodes as well. But how would that be correctly integrated into
> the ROS repository structure? Does that nearly empty "virtual" package
> in a subdirectory pose a problem? Would you mind adding a repository to
> the list of ROS repositories that just contains one library?
>
>  From what I've seen with other external libraries (e.g. Eigen, OpenCV),
> the ROS package is a similar forwarding package which in addition
> downloads and installs the library from an external location. That would
> also work, we could put the ROS octomap in our existing "alufr-ros-pkg"
> ROS repository, which would then pull the code from the "real"
> octomap-SVN at sourceforge. It just didn't seem the right thing to do to
> create another step for installing and downloading when you have control
> over the original repository anyways. Plus, we would need to take care
> that the code in the two repositories stays in sync in terms of the API,
> instead of changing things only in one place.
>
> Maybe there are other ideas on what to do (e.g. with svn:externals?), or
> is the current repository / folder structure the way to go?
>
> 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
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>