install(EXPORT): Handling /lib to /usr/lib symlink while computing prefix
System information:
$ cmake --version
cmake version 3.18.4
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 21.10
Release: 21.10
Codename: impish
Question:
When I try to build pybind11 from source with cmake 3.18.4 it produces an install(TARGET)
file (pybind11Targets.cmake
) like this:
# Generated by CMake
if("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" LESS 2.5)
message(FATAL_ERROR "CMake >= 2.6.0 required")
endif()
cmake_policy(PUSH)
cmake_policy(VERSION 2.6...3.17)
#----------------------------------------------------------------
# Generated CMake target import file.
#----------------------------------------------------------------
and further down the file it computes the import prefix like this:
[...]
# 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)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
this is a problem since the variable ${CMAKE_CURRENT_LIST_FILE}
is located in /lib/cmake/pybind11/
where /lib
is a symlink to /usr/lib
and the four calls to get_filename_component(PATH)
above will reach the root folder instead of the /usr
folder (which would be reached of the real path of the symlink was used.
I can see from the cmake source that the current behavior is to use get_filename_component(REALPATH)
instead of get_filename_component(PATH)
.
The result of using the wrong import prefix is that the installed pybind11 cmake tools does not work correctly.
I wonder if the problem is the cmake_policy(VERSION 2.6...3.17)
line ? Was the REALPATH
behavior introduced after 2.6?