-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[CMake] Set rpath
for individual targets and not globally
#19501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
5417d48
to
fa6f67f
Compare
fa6f67f
to
88740e0
Compare
Test Results 19 files 19 suites 3d 4h 23m 44s ⏱️ Results for commit 7af2b1d. ♻️ This comment has been updated with latest results. |
88740e0
to
2342063
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but I added a few more suggestions.
When using the `rpath=ON` option, the global CMake variable `CMAKE_INSTALL_RPATH` is mutated, which is problematic in several corner cases. This commit suggests to append the rpaths at the target property level, and also set the rpaths for the build tree separately so they make sense. A new ROOT macro is introduced for this rpath setting, which are also used for the PyROOT libraries, which also need custom rpaths. Closes root-project#19327 and root-project#19134.
Since ROOT 6.36, the relative `RPATH` to the main ROOT libraries is only appended to the existing path, and not replacing the path that is e.g. passed by the user via `CMAKE_INSTALL_RPATH`. Therefore, there is no problematic side effect of `rpath=ON` anymore. We can drop this option and always append to the runpath. This makes the ROOT configuration less confusing, also because from the option name "rpath", it is not clear what it did.
2342063
to
7af2b1d
Compare
I think this PR results in a breaking change that |
When using the
rpath=ON
option, the global CMake variableCMAKE_INSTALL_RPATH
is mutated, which is problematic in several corner cases.Furthermore, the path is set to match the install tree, resulting in nonsensical relative rpath for the build tree if the directory structure is different (e.g. because of
gnuinstall=ON
).This commit suggests to append the rpaths at the target property level, and also set the rpaths for the build tree separately so they make sense.
New ROOT macros are introduced for this rpath setting, which are also used for the PyROOT libraries, which also need custom rpaths.
Closes #19327 and #19134.
Here are some rpaths for relevant libraries and executables with
gnuinstall=ON
andrpath=ON
, before and after this PR: