[CMake] What is a good way to exclude default library locations from install-tree rpaths?

[Alan W. Irwin]

Hi Alex:

On 2010-02-03 21:47+0100 Alexander Neundorf wrote:

> On Tuesday 02 February 2010, Alan W. Irwin wrote:
> ...
>> So to summarize this, I plan to filter all the many INSTALL_RPATH target
>> properties I set in various parts of our build system for our applications
>> and libraries using the CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES variable,
>> but a much cleaner way to do this would be if CMake itself automatically
>> filtered INSTALL_RPATH.  Therefore, I hope that CMake fix is implemented.
>> (I assume here you always want to filter out the standard locations from
>> rpath for the installed applications and libraries.  This is the assumption
>> CMake appears to make for the build-tree versions of those applications and
>> libraries.)
>>
>> Is that a trivial fix or do you want me to make a wish-list bug so the idea
>> doesn't get lost?
>
> Wish-list bug.

Done, see 0010238.

> But before you do that, I would suggest that you try to use
> INSTALL_RPATH_USE_LINK_PATH. This will add all RPATHs which are in the build
> tree RPATH.

It turns out I am going to have to filter all rpath information with
explicit CMake code regardless because we need that information for the
pkg-config files we generate for each of our libraries.  We support
pkg-config that way since it is ideal for our users who simply want to
compile their application against PLplot by hand; using a simple Makefile
approach; using any non-CMake build system; or using a CMake-based build
system.  Of course, if they decide to build their application with CMake, we
also give them an option to use EXPORTed library information as well.  I
presume for the KDE case you also EXPORT, but I guess you don't support
pkg-config for some reason.  Of course, your way largely forces everybody
who wants to link their application against KDE libraries to use cmake to do
so, but we like to give our users more options than that.  :-)

Out of curiosity I did do the experiment that showed
INSTALL_RPATH_USE_LINK_PATH propagated the filtered build-tree rpath results
to the installed version of one of our libraries confirming exactly what you
said.  However, for the above reason I will stick with using INSTALL_RPATH
instead (since I have to collect that filtered rpath information in any case
for the pkg-config files we generate).   So the only change I will be doing
to PLplot is to implement a function to filter rpath results using
CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES and to call that function
wherever I collect RPATH information in our build system.

So if the above feature request is implemented it would not actually be used
by the PLplot build since we have to generate the explicit filtered RPATH 
by special CMake code to configure our pkg-config files properly.  However,
I made the above feature request anyway simply based on the consistency
principal that rpath information in the build tree and install tree (as
generated by INSTALL_RPATH or by INSTALL_RPATH_USE_LINK_PATH) should all be
filtered in exactly the same way.

Thanks again for bringing CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES to my
attention.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________