Project

General

Profile

Actions
Copy link

Pull request #432

open

hpp-fcl -> coal

Added by Guilhem Saurel 5 days ago. Updated about 14 hours ago.

Status:
New
Priority:
Normal
Assignee:
-
Repository URL:
https://github.com/nim65s/robotpkg
Repository branch:
master

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

Actions
Copy link
 #1

Updated by Anthony Mallet 2 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.

Actions
Copy link
 #2

Updated by Guilhem Saurel 1 day 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.

Actions
Copy link
 #3

Updated by Anthony Mallet about 15 hours 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.

Actions
Copy link
 #4

Updated by Guilhem Saurel about 15 hours 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

Actions
Copy link
 #5

Updated by Anthony Mallet about 14 hours 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.

Actions
Copy link

Also available in: Atom PDF