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

[Brian Gerkey]

On Mon, Apr 26, 2010 at 1:27 AM, Armin Hornung
<HornungA at informatik.uni-freiburg.de> wrote:
> 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?

Sorry, there's not any further documentation at this point.  You can
always have a look at the file, mk/svn_checkout.mk.  It's not very
complicated.

Btw, we're switching away from doing SVN checkouts of third-party code
during the build.  We've found that it leads to frequent build
failures, when one of the many SVN servers is down, unreachable, or
just slow.  Instead, we make a tarball of an svn export and store it
locally on one of our servers, then download the tarball during the
build (via mk/download_unpack_build,
http://www.ros.org/wiki/mk#A3rdparty_code.2C_from_tarball).
Retrieving a tarball is much faster than doing an SVN checkout, and by
keeping all the tarballs on one server, we minimize the possible
points of failure.

You can see an example of the tarball approach in the gmapping
package. The downside of the approach is that it's more work to
upgrade to a newer version of the third-party code.  If you're
updating that version frequently, then you might want to stick with
SVN.

> How do people usually deal with $SVN_REVISION, adjust it in the wrapping
> ROS package for every "stable" release of the lib?

Yes, we increment it explicitly when we want a newer version of the
third-party lib.  The Makefile structure guarantees that the
third-party code will then be checked out afresh.  While specifying
SVN_REVISION is optional, we found that it's important to version-lock
every third-party download, to avoid ambiguity as what people are
actually running.

	brian.