Re: [ros-users] Managing software packages containing upstre…

The general rule is:

* released stacks: may not do an SCM checking *during* build
* unreleased stacks: may do whatever they want

Your technique follows either of these rules. That said, the git
submodule has its own pros and cons.

In Fuerte, we are deploying infrastructure to make it easier to
package thirdparty libraries sans-wrapping (e.g. opencv, pcl,
octomap); this mechanism should be more widely available in Groovy.

- Ken

2012/3/19 Stéphane Magnenat <stephane.magnenat@mavt.ethz.ch>:
> Hi all,
>
> As maintainer of software packages that include one or more libraries and a
> ROS wrapper [1], I have been a bit dissatisfied with the existing proposals
> to wrap third-party libraries, because they all require the libraries to be
> available as tarballs. While I understand the rationale for stable and
> released external libraries; it is really a problem in the research context
> when these libraries are moving quickly, and one still want to provide an
> up-to-date ROS wrapper for use by colleagues, students, and the community.
>
> I therefore propose a new way to handle these, on which I would like your
> opinion. It applies to the context of git-based repositories, but the same
> idea would be valid for svn. The idea is to use "git submodule" to fetch a
> specific revision of the libraries' source code into a upstream_src/
> directory in wrapper packages, and then to use a simple Makefile to build
> them. I did it in ethzal_mapping for libnabo and libpointmatcher [2] and it
> works fine. Compared to alternative methods, it skips the step of building
> tarballs while still referencing the version of the libraries inside the
> wrapper packages.
>
> What do you think?
>
> Kind regards,
>
> Stéphane
>
>
> [1] for instance modular_cloud_matcher, which depends on libnabo and
> libpointmatcher
> [2] https://github.com/ethz-asl/ros-mapping
>
> --
> Dr Stéphane Magnenat
> http://stephane.magnenat.net
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users