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"
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Reply via email to