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