Pull request #432
openhpp-fcl -> coal
Description
Hello,
The "hpp-fcl" project was renamed into "coal", and reached v3.
Here are also more minor changes to eigenpy and pinocchio.
I also updated jrl-cmakmodules "DEPEND_ABI.cmake+= cmake>=3.10", as this has been required for one year in https://github.com/jrl-umi3218/jrl-cmakemodules/pull/621, but that condition is not true for packages that use the jrl-cmakemodules and did not get any new release for more than one year.
I my test, this pull request break a few leaf packages (aig, dynacom, and solo-pybullet), but I'll handle this later.
Also, a "sed -i 's/hpp-fcl/coal/' wip/*/Makefile" or similar will is required after merging, or else we could add some symbolic link, I'm not sure how you would prefer to handle packages renaming.
Best,
Guilhem
Updated by Anthony Mallet 8 days ago
Thanks.
I just added a revision bump for dependent package of hpp-fcl and a
CONFLICTS directive for coal with hpp-fcl. Otherwise looks good.
Updated by Guilhem Saurel 8 days ago
I did not think about the REVISION, I should have. But for that CONFLICTS, I thought I did it ! Anyways, thanks for the review :)
Looking at the first bulk mails, I think we can drop support for 18.04 and 18.04-pal. If it is possible to keep the current apt repository alive, that can still help, but I don't think maintain build VMs for those still make sense.
Updated by Anthony Mallet 7 days ago
On Monday 25 Nov 2024, at 16:10, Guilhem Saurel wrote:
Looking at the first bulk mails, I think we can drop support
for 18.04 and 18.04-pal. If it is possible to keep the current apt
repository alive, that can still help, but I don't think maintain
build VMs for those still make sense.
OK, I'll drop them at some point. The repositories are always kept
online, but not updated of course, at least as long as there is no
disk space issue.
I fixed another weird issue with cmake in coal: the exported targets
were not containing the header path and libraries paths for
octomap (that might come from /opt/ros, depending on how you configure
robotpkg, and of course those are not compatible with those in
/usr). It looks like an issue with cmake, but it's impossible to
figure out why it does not do the right thing. This is basically the
same issue as with omniORB paths that was fixed a few days ago.
Updated by Guilhem Saurel 7 days ago
Hum, maybe the issue with octomap is that sometimes the CMake export is called "octomap", and sometimes "octomap::octomap" or something like that, I'll try to double check that
Updated by Anthony Mallet 7 days ago
I don't see anything wrong regarding the header path:
- octomap-targets.cmake has this :
set_target_properties(octomap PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include" ...
- coal/src/CMakeLists.txt has this:
MODERNIZE_TARGET_LINK_LIBRARIES(${PROJECT_NAME} SCOPE PUBLIC TARGETS octomap ...
which is supposed to eventually do this IIUC:target_link_libraries(coal PUBLIC octomap)
But the resulting coalTargets.cmake is missing the required
-I/opt/ros/noetic/include in INTERFACE_INCLUDE_DIRECTORIES without my
patch, and the build is failing in path/hpp-affordance (on my machine
only, because for some reason I have a config pulling octomap from
/opt/ros).
Also, it shows an INTERFACE_LINK_LIBRARIES with just "octomap",
without any path, but /opt/ros/noetic/share/octomap-targets.cmake is missing an
INTERFACE_LINK_DIRECTORIES. That may explain why. Or not. Puzzled :)
In any case (without my patch), it's linking hpp-affordance with
just -loctomap, pulling /usr/lib/liboctomap.so, which is wrong.