Follow PDAL's CMake RPATH strategy #2009
Conversation
There was a problem hiding this comment.
A minor nit is that cmakelint will suggest lower-case functions set(...) and if(APPLE) for consistency.
I don't have any preference on handling RPATH, but I'll take your word on PDAL's experience.
Further reading on this topic is found here, which describes various RPATH strategies.
|
Is this considered a bug fix for 7.0.1 or a feature for 7.1.0? |
|
Feature for 7.1, but the Conda builds might have to apply this patch to 7.0.x for a while. |
Right, thanks. I'm keeping an eye on the conda-forge PROJ package and will keep them posted about this when the 7.0.0 package is on it's way. |
|
them (conda) == me also, so I'm happy to help babysit it there too. |
… appear to be obsolete given current CMake versions (fixes OSGeo#3029) And specifically remove set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) which was the only setting at a non-default value.
… appear to be obsolete given current CMake versions (fixes OSGeo#3029) And specifically remove set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) which was the only setting at a non-default value.
CMake: remove all Mac specific settings added per #2009, …
PDAL's RPATH strategy on CMake has worked well for us, and PROJ should consider following suit.
Review it at https://github.com/PDAL/PDAL/blob/master/cmake/rpath.cmake