[CMake] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX is "/"
Ben Keller
irods.ben.keller at gmail.com
Mon May 9 18:01:11 EDT 2016
CMake version 3.5.0
When exporting from a project, the PROJECTTargets.cmake file contains logic
for computing the _IMPORT_PREFIX. This _IMPORT_PREFIX is then used in the
PROJECTTargets-<configuration>.cmake to generate
the IMPORTED_LOCATION_<uppercase-configuration>. If _IMPORT_PREFIX is "/",
then the IMPORTED_LOCATION_ properties all start with two leading slashes
("//").
Exactly two leading slashes is apparently a special case in POSIX file
paths, such that its interpretation is left up to the implementation. As
best as I can tell, the PROJECTTargets.cmake file should be setting
_IMPORT_PREFIX to the empty string instead of "/" to prevent the double
leading slashes in PROJECTTargets-<configuration>.cmake.
A result of this is that when importing a library installed to /usr/lib,
the IMPORTED_LOCATION_DEBUG ends up being "//usr/lib/libmylib.so". CMake
doesn't contract the two leading slashes (as it apparently shouldn't), so
executables linking against the mylib target end up with "//usr/lib" in
their RPATH.
Example of generated cmake code:
[ -- From PROJECTTargets.cmake -- ]
# Compute the installation prefix relative to this file.
get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
[ -- From PROJECTTargets-<configuration>.cmake -- ]
IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/path/to/file.so"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160509/8bf32d0f/attachment.html>
More information about the CMake
mailing list