Update KDL SegmentMap interface to use shared pointers

[jensenb]

This is a dependent change for the orocos KDL API modification discussed in: orocos/orocos_kinematics_dynamics#4

To summarize the KDL API used incomplete type definitions in STL containers, which is undefined behaviour according the c++ standard. As it was, GCC / libstc++ handles this behaviour with problems; however, on systems with clang/libc++ using incomplete type definitions in STL containers results in compilation errors. Instead a solution involving shared pointers has been proposed. More rational the change is discussed in the upstream pull request.

The upstream pull request is necessary for this change to be merged.

[wjwwood]

@jensenb I don't think this can be released into hydro until the updated version of orocos_kdl is released into hydro, will it be an API breaking change?

In order to merge this now, I would want to see a backwards compatible change, potentially using #ifdef's to have two code paths for different versions of orocos_kdl. If not this then we should probably target this release for indigo (next version of ROS).

Also, if this will only work with newer versions then this package (or kdl_parser) should have a versioned dependency on orocos_kdl.

[jensenb]

Yes the orocos_kdl upstream change will mandate a (slight) API change. From my perspective, there really is no way around this. Their self referential tree data structure has undefined behaviour, and while it works currently fine with gcc and libstc++, it is not guaranteed to work with all standards conforming c++ compiler and standard library implementations, nor is it guaranteed to work with newer versions of gcc/libstdc++.

I opened this change request so that:

• the KDL guys could see the downstream effects of the API change
• Mavericks users could pull this change and at least get hydro to compile on their systems.

I don't know how much code uses KDL, but I think it would be cleaner and much more maintainable if only one API version was supported. Once the KDL guys have decided how they want to handle the problem and committed the change with proper version info, then the development branch could just switch to the new version using this change. I mean, does the devel branch and do future releases of robot_state_publisher and robot_model really have to support an older version of KDL? People who the need the change now (Mavericks users), will just have to use devel branch until the next ROS release.

I would hold on on this change until the KDL team decides what to do about the problem.

[wjwwood]

I agree that we wait to see what the Orocos developers do, please ping back here when there is progress, otherwise it will likely fall through the cracks.

[jensenb]

Updated this PR to reflect the newest changes in the upstream pull request.

[jensenb]

I completely forgot to check up on the PR, is there anything holding this back currently from being merged into hydo-devel and indigo-devel?

[NikolausDemmel]

bump

EDIT: The bump is about getting these changes released into hydro/indigo in a coordinatd fashion: ros/robot_model#43, #5, #4, #19

[NikolausDemmel]

Now that orocos_kdl has been re-released (https://github.com/smits/orocos-kdl-release) including the patch that this PR depends on, can we merge this, forward-port the patch to indigo, and then possibly some time get a hydro and an indigo release?

[wjwwood]

Same comment here as with ros/robot_model#43, @isucan I can do this for you if you're ok with the change.

[isucan]

Thanks @wjwwood !