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
__________________________
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
