Better support for GNU/Stow-like symlink trees
The find_package() @PACKAGE_INIT@ boilerplate resolves relocatable paths relative to the CMAKE_CURRENT_LIST_DIR, which works most of the time, but breaks apart in scenarios where the installation is referenced through a symlink tree.
MR !2732 (closed) attempted to fix this issue by resolving the CMAKE_CURRENT_LIST_DIR using realpath early on, which dereferences the symlink before walking up the tree.
For example, imagine two projects A and B:
a/
include/A.h
share/cmake/a/a-config.cmake
b/
include/B.h
share/cmake/b/b-config.cmake
When aggregated using GNU stow (Gobo Linux is one example where this approach is taken) we end up with a unified tree that looks like this:
combined/
include/A.h
include/B.h
share/cmake/a/a-config.cmake
share/cmake/b/b-config.cmake
The share/cmake/{a,b}
paths symlink into their respective real directories, but because of the logic in @PACKAGE_INIT@
the include paths for b
end up as combined/include
, which ends up also containing the headers for project a, which is undesirable.
For example, if someone wants to override either project in a sandbox, and still compile against the combined tree (to find the other project), it is not possible because we end up with the combined paths.
By resolving the symlink early like in !2732 (closed) we end up with the actual b/share/cmake/...
directory, and the include paths end up resolving to b/include
, which does not include a's headers.
This proposal does not interfere with 6c613b43 because the logic to handle that also ends up using REALPATH
.