On 06/18/2012 03:48 AM, Tully Foote wrote:
> Hi Rich,
>
> Due to a long history of interweaved lineage PCL and ROS datatypes
> collide. We have not forked PCL as much as applied a patch to make it
> use our generated messages instead of the stripped down versions built
> into PCL. This previously was done inside PCL upstream, however it
> has proven easier to patch new releases than maintain the
> functionality within PCL. Also it does not require PCL to have
> anything ROS specific inside it's release. The git-buildpackages
> repositories allow us to reimport upstream and reapply our patches on
> top of new releases as they come out. If there is a patch release to
> the version we have used we can take it up, and plan to. We cannot
> take up major API breaking releases.
>
> There has also been an initiative to release renamespaced versions of
> pcl 1.6 as pcl16 as a backport into Electric. I'm not sure of the
> current status of that effort.
>
> Tully
Hi Tully,
Thanks for the reply. I guess fork wasn't the best way to describe it,
it is just a handful of files being added/modified on top of PCL's
upstream releases.
From a distribution maintainer's perspective, it would be nice to
decouple the upstream PCL releases from ROS altogether. Ideally, ROS
would build against a stand-alone version of PCL without modification.
Since this is not an option due to the datatype interdependence, the
next best thing would be to treat ROS as an optional dependency to PCL
(it already partly is: PCL looks for ROS to determine whether or not it
should use its included copies of sensor_msgs and std_msgs, or defer to
ROS' copies.) Since the interdependence is already there, it made
sense to me to take the next step and include the ROS message headers
for the point cloud messages as well (when USE_ROS was enabled), and
that was the path I started to go down. With that, as long as the
message definitions don't change too much once a PCL release is made,
you could lock ROS to depend on a specific version of PCL. You could
even going so far as to version the stack's name: pcl-1.5 instead of
pcl; this would also lend itself to creating explicit dependencies on
newer backports, and letting API-compatible point-releases in without
any modification.
I understand that ROS development moves quite fast and isn't
necessarially tied to anything the PCL guys are doing, so keeping a
separate copy with the requisite modifications makes it easer to make
modifications as ROS evolves. Grabbing the latest changes from the wg
repository for distribution packaging with ROS isn't the end of the
world, and we can do that if it ends up being the best solution. But if
the messages and ROS stack info aren't changing that often, having PCL
optionally treat itself as its own self-contained stack might be worth
considering.
Rich
(text/plain)