Hi @traversaro. I tried going through the original issue but my lack of familiarity with that project is hindering my progress.

Can you please explain the issue in more detail? It seems like this affects Apple Silicon (e.g. M1) specifically, so I'd like to understand this in significant detail.

Hi @traversaro. I tried going through the original issue but my lack of familiarity with that project is hindering my progress.

Sure! Sorry, I opened the issue quickly to avoid forgetting about this.

Can you please explain the issue in more detail? It seems like this affects Apple Silicon (e.g. M1) specifically, so I'd like to understand this in significant detail.

The behavior of setting CMAKE_MACOSX_RPATH to 0 is:

• unexpected for most users of CMake, as the CMAKE_MACOSX_RPATH defaults to 1 since CMake 3.0 (released in June 2014)
• undocumented, as in the documentation in https://cmake.org/cmake/help/latest/prop_tgt/MACOSX_RPATH.html#prop_tgt:MACOSX_RPATH only the behaviour when CMAKE_MACOSX_RPATH is 1/TRUE, and not when CMAKE_MACOSX_RPATH is 0/FALSE

While this does not mean that setting CMAKE_MACOSX_RPATH to 0 is wrong or a bug, this may lead to hard to debug behaviours like the one that we encountered in conda-forge/gtsam-feedstock#15 (comment), that is just an example and of which there is no need to understand all the details.

With this PR I wanted to:

• bring to the attention of gtsam devs the possible problem of setting CMAKE_MACOSX_RPATH instead of using its default value
• check if CI tests pass fine if we just use the default value of CMAKE_MACOSX_RPATH

In case CMAKE_MACOSX_RPATH is actually needed for anything, I think we can probably achieve the same result setting appropriate default values for the more widely used CMake variables CMAKE_SKIP_RPATH, CMAKE_SKIP_BUILD_RPATH andCMAKE_SKIP_INSTALL_RPATH.

In the conda-forge specific case, avoiding to set CMAKE_MACOSX_RPATH to 0 permitted to avoid had to manually modify the install_path of the library as done in https://github.com/borglab/gtsam-manylinux-build/blob/389fa7e6a8d2dacaf6cb2e3a3590436c476c630b/build-macos-new.sh#L144 . However, the case of building pypi packages may be different, so I would need to double check this.

@traversaro thank you for the explanation. Given your point that the default value is 1 and has been since 2014 gives me enough reason to approve this PR. Especially with the CI passing.

Thanks for merging! Feel free to open issue and tag me if you find problems with these, for example in pypi wheel generation.