[macOS] Fix compilation and linking issues in MoveIt2

[idesign0]

This Pull Request addresses several critical compilation and linking issues encountered in the MoveIt2 framework specifically on macOS operating systems. These fixes primarily involve correcting CMake targets, ensuring proper library linking, and updating dependency usage to adhere to modern CMake practices.

---

🔍 Changes Detailed by Package

1️⃣ Pilz Industrial Motion Planner

Corrected linking errors by ensuring necessary dependencies are explicitly linked, resolving issues where macOS would fail to find symbols for joint_limits_common.

• Fixed: Linking errors with joint_limits_common.
• Updated: Library dependencies so that planning_context_loader_base and trajectory_generation_common correctly link to joint_limits_common.
• Before: planning_context_loader_base did not link to joint_limits_common.
• After (Example Snippet):

  target_link_libraries(planning_context_loader_base cartesian_limits_parameters joint_limits_common)
  target_link_libraries(trajectory_generation_common cartesian_limits_parameters joint_limits_common)

2️⃣ MoveIt Python Utils (moveit_py_utils)

Added explicit linking to the Python 3 library to resolve linking errors encountered during the build process on macOS.

• Fixed: Linking errors by adding a direct link to the Python library.
• Change:

  target_link_libraries(moveit_py_utils Python3::Python)

3️⃣ FMT Library Fixes

• moveit_setup_framework: Added the necessary header to support the use of fmt::join in urdf_config.cpp, specifically targeting the version-compatible header:

  #include <fmt/ranges.h> 

4️⃣ MoveIt Perception

Addressed specific library requirements for graphics and image processing on macOS.

• OpenGL Libraries: Fixed linking for OpenGL libraries on macOS by using FreeGLUT and GLEW:

  if(APPLE)
    find_package(FreeGLUT REQUIRED)
    set(SYSTEM_GL_LIBRARIES GLEW::GLEW FreeGLUT::freeglut)
  else()
  # ... existing logic

• OpenCV Linking: Added necessary linking for the semantic world module with OpenCV:

  target_link_libraries(moveit_semantic_world PRIVATE ${OpenCV_LIBRARIES})

---

✅ Summary

• This PR fixes all known macOS-specific compilation and linking errors within the affected MoveIt2 packages.
• CMakeLists files have been updated to utilize modern CMake targets where applicable (Python3::Python).
• No functional changes have been made to MoveIt's runtime behavior; this is purely a build-system improvement.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.18%. Comparing base (ea9d587) to head (c13a035).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3631      +/-   ##
==========================================
+ Coverage   46.15%   46.18%   +0.03%     
==========================================
  Files         726      726              
  Lines       59418    59419       +1     
  Branches     7618     7620       +2     
==========================================
+ Hits        27416    27434      +18     
+ Misses      31835    31818      -17     
  Partials      167      167              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[EzraBrooks]

hey @traversaro are you able to confirm that these are needed? isn't moveit2 building for macOS in RoboStack already?

[traversaro]

hey @traversaro are you able to confirm that these are needed? isn't moveit2 building for macOS in RoboStack already?

Sure, MoveIt2 is indeed building on macOS in RoboStack. However, what we do in RoboStack and what @idesign0 is doing in https://github.com/idesign0/ros2_macOS has some differences, that could explain why some differences (but a lot of patches and fixes are shared):

• In RoboStack we use dependencies from conda-forge, in @idesign0 repo dependencies are installed from homebrew
• In RoboStack we use vanilla clang compiler, @idesign0 repo uses the so-called Apple Clang variant (the one installed by Xcode)
• RoboStack uses a Python that statically links libpython, @idesign0 one that dynamically inks to libpython.

@idesign0 to avoid confusion do you think it make sense to mention Homebrew in these kind of PRs?

Beside that, I try to contribute all the patches in RoboStack upstream as fast as possible, but sometimes I miss some patches, so it is possible that some fixes that @idesign0 is proposing is actually in some patch that we forgot to submit upstream.

I can add more comments inline.

[traversaro]

Ok, I checked and all the changes make change to me, some indeed reflect fixes that were done also in robostack but not upstreamed.

[idesign0]

Ok, I checked and all the changes make change to me, some indeed reflect fixes that were done also in robostack but not upstreamed.

@traversaro Thanks for the review and the clarification — really helpful as always! I’ll make sure to mention Homebrew in future PRs to avoid confusion. 😅

Regarding the patches: should I keep them if RoboStack already has the same fixes but they aren’t upstreamed yet?
I’ll update the PR once I have your preference.

[traversaro]

Regarding the patches: should I keep them if RoboStack already has the same fixes but they aren’t upstreamed yet?

Yes, definitely! If we are able to upstream them, we can remove them from RoboStack, and non-RoboStack users can enjoy them, so it is really good to upstream them. I just cross-reference the robostack patches to answer @EzraBrooks question.

[EzraBrooks]

happy to approve and merge once Silvio is happy with your changes since he knows more about this than I do!

[idesign0]

Suggestions compile fine locally.

[EzraBrooks]

I approve if Silvio does, though we're still blocked by rolling CI being borked..