|
Notes |
|
|
(0020655)
|
|
Alex Neundorf
|
|
2010-05-08 03:44
|
|
Hmm, one could argue that if you tell cmake to put this into the RPATH, then it also should do just that.
Why are you not using INSTALL_RPATH_USE_LINK_PATH ?
I think a useful improvement to INSTALL_RPATH_USE_LINK_PATH would be if it would also add the RPATH of libraries which are used and install with the current project.
Currently it uses all RPATHs from external libraries, and removes the one which were pointing inside the buildtree. So it would be cool if it would, instead of removing those paths, add the install dirs of these in-project targets to the install RPATH.
Would that help in your case ?
Alex |
|
|
|
(0020665)
|
|
irwin
|
|
2010-05-08 12:20
|
|
"Hmm, one could argue that if you tell cmake to put this into the RPATH, then it also should do just that."
Sure, but then you have the current inconsistency with how rpath is automatically determined in the build tree with the standard library locations filtered out. Furthermore, if you automatically filter out standard library locations from INSTALL_RPATH it does no harm while also providing a useful service (standard locations in the various rpath lists that are combined together by PLplot into the final list used by INSTALL_RPATH make a real mess since if say "/usr/lib" is at the top of the combined list by chance, that means you access the system libraries at run time rather than the ones that you specified in the non-standard locations.)
"Why are you not using INSTALL_RPATH_USE_LINK_PATH ?"
PLplot needs everything given by INSTALL_RPATH_USE_LINK_PATH as well as one additional location (the install location of the PLplot libraries). (N.B. that extra location is optional but useful for those who want to install PLplot into a non-standard location.) We could specify that extra location with INSTALL_RPATH, but I am pretty sure I tried that years ago and it conflicted with INSTALL_RPATH_USE_LINK_PATH. Can you specify both INSTALL_RPATH and INSTALL_RPATH_USE_LINK_PATH now and get a good combined result? |
|
|
|
(0020667)
|
|
Alex Neundorf
|
|
2010-05-08 17:12
|
|
"Can you specify both INSTALL_RPATH and INSTALL_RPATH_USE_LINK_PATH now and get a good combined result?"
Yes. We do that in KDE.
What do you think about the idea to improve INSTALL_RPATH_USE_LINK_PATH so that it also adds the install location of linked in-project libraries ?
Alex |
|
|
|
(0020670)
|
|
irwin
|
|
2010-05-08 19:37
|
|
"What do you think about the idea to improve INSTALL_RPATH_USE_LINK_PATH so that it also adds the install location of linked in-project libraries ?"
We have some dynamically loaded plug-ins that are installed in a special directory but which need rpath pointing to our normal installed library location. So that would be counterproductive in that case (unless you specified an additional variable to specify the path you wanted to point to, and it appears from what you said above that INSTALL_RPATH already does that job.
So let's get back to my original request. There is no possible harm in that, and it is still quite a useful idea, I think. |
|
|
|
(0020685)
|
|
Modestas Vainius
|
|
2010-05-09 07:14
|
|
|
Well, I don't think that cmake should filter anything what's explicitly specified. Since user explicit specifies INSTALL_RPATH, cmake should not get in between and disregard user wishes by doing some magic. I do believe this will lead to more WTH moments than it's worth. |
|
|
|
(0020688)
|
|
irwin
|
|
2010-05-09 14:44
|
|
I also hate magic, but the answer is documentation. So I agree with you to
this extent; if filtering of INSTALL_RPATH is implemented, it should be well documented.
The two real questions for the CMake developers are
(1) Is the filtering useful?
(2) Could it ever be harmful?
Suppose through lots of obscure CMake manipulations (usually through find modules of some kind for each external library) you get the following list for INSTALL_RPATH for three separate external libraries:
externlib1path;externlib2path;externlib3path
where externlib2path is a standard location (e.g., "/usr/lib"), and externlib[13]path are non-standard locations. That /usr/lib in the list causes big trouble for the important case where there is an old externlib3 in /usr/lib and you want to use a newer version installed in some non-standard location. (That happens a lot with Qt4 and PLplot where often I want to try out a new version of Qt4 downloaded directly from trolltech.) Instead of using the desired new version you end up with the old system version. So the answer to the first question above is an emphatic yes. Of course, the answer to the second question is an emphatic no since libraries are always searched for at run time in the standard locations as a last resort.
I guess if you can find a counterexample where a standard system location in the middle of a bunch of rpath alternatives is actually useful for a build of a real project, then you have a point, but I frankly cannot imagine such a case. |
|
|
|
(0024820)
|
|
Brad King
|
|
2011-01-17 16:26
|
|
I agree with 0010238:0020685 that we should not mess with anything that is set explicitly. INSTALL_RPATH is a primitive that we honor blindly. Any filtering should be up to the project based on its own needs.
Generally one can use INSTALL_RPATH_USE_LINK_PATH for third-party dependencies and INSTALL_RPATH for locations installed by the project. |
|