[ros-users] Importing / including a new library into ROS (OctoMap)

[Brian Gerkey]

hi Armin,

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.

E.g., to retrieve octomap via rosinstall, you'd have to specify /trunk
of your repo, so that it would get octomap itself, plus the 'ros'
subdirectory.  But rosinstall would add /trunk to ROS_PACKAGE_PATH,
because it doesn't know any better.  In practice, this would likely
only cause minor performance issues (because rospack would dive into
the octomap source tree looking for packages whenever it did a crawl).

You'd also have problems using our toolchain to build binary (e.g.,
Debian) packages; I don't know wheter the octomap part of the tree,
not being inside a package, would carry over into the binaries.  And
if this works now, it probably won't later, once rosbuild learns how
to do an 'install'.

But if you prefer to keep it the way you have it now, we don't
certainly don't mind adding a small repository to our list.

	brian.

On Fri, Apr 23, 2010 at 1:56 AM, Armin Hornung
<HornungA at 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 at 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 at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>