Remove octomap dependency#269
Conversation
The versioned dependency doesn't work out on the latest ubuntu release. However, since compatibility to libfcl-dev is mentioned in the comment: Octomap should be linked in as a transitive depencency from fcl. In fact, octomap isn't linked to the target, anyway, but fcl is. Looking at the built library it seems that it seems to be correctly linked against liboctomap. Since it's used a private link target (only used from within a CPP file and fcl being linked privately) it should be save to remove the dependency altogether, at least from my understanding.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## ros2 #269 +/- ##
=======================================
Coverage 69.04% 69.04%
=======================================
Files 21 21
Lines 3368 3368
Branches 325 325
=======================================
Hits 2325 2325
Misses 932 932
Partials 111 111 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I would expect that as long as fcl is built correctly against octomap, it will expose the correct library. Thus, it might help with that issue, as well. |
|
@tylerjw @rhaschke Since this is blocking MoveIt on lyrical (https://build.ros2.org/view/Lbin_uR64/job/Lbin_uR64__geometric_shapes__ubuntu_resolute_amd64__binary/49/console) can you please release a new version with this fix? |
|
I'm not part of the MoveIt2 maintainer team. Nevertheless, I triggered a new release: ros/rosdistro#51930 Please, @moveit/maintainers take care of the MoveIt2 release process in a more pro-active fashion in the future. |
|
@rhaschke Thanks. Could you do this also for the other distributions? |
Which distributions exactly? |
Well, at least for |
The versioned dependency doesn't work out on the latest ubuntu release. However, since compatibility to libfcl-dev is mentioned in the comment: Octomap should be linked in as a transitive depencency from fcl.
In fact, octomap isn't linked to the target, anyway, but fcl is. Looking at the built library it seems that it seems to be correctly linked against liboctomap:
Since it's used a private link target (only used from within a CPP file and fcl being linked privately) it should be save to remove the dependency altogether, at least from my understanding.
Tested to build locally in a resolute-rolling docker container.
This is from my point of view one way to address #268