[ros-users] Deb source packages

[Bhaskara Marthi]

On Mon, Jun 18, 2012 at 2:06 PM, Jack O'Quin <jack.oquin at gmail.com> wrote:
> On Mon, Jun 18, 2012 at 1:50 PM, Rich Mattes <richmattes at gmail.com> wrote:
>> 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.
>
> Problems with people trying to build PCL from source to run with ROS
> are very common on answers.ros.org.
>
> Their usual motives are:
>
>  1) getting a more recent version than shipped with the ROS distro
>
>  2) needing to fulfill the rosdep dependency on some non-Ubuntu system
>
> We need a clear, well-documented method to accomplish that task.

We've been using pcl trunk with fuerte:
https://bitbucket.org/bhaskara/perception_pcl_fuerte_unstable

It puts the pcl trunk code into a 'pcl16' namespace, so that it can
coexist with fuerte's pcl 1.5.  Using it basically involves replacing
the pcl and pcl_ros namespaces with pcl16 and pcl16_ros respectively.
- Bhaskara


> --
>  joq
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users



-- 
Bhaskara Marthi
Research Scientist
Willow Garage Inc.
650-475-2856