Page MenuHomePhabricator

[clang] cmake: resolve symlinks in ClangConfig.cmake
AbandonedPublic

Authored by Lekensteyn on May 7 2018, 6:00 AM.

Details

Summary

Ensure that symlinks such as /usr/lib/cmake/clang-X.Y (pointing to
/usr/lib/llvm-X.Y/lib/cmake/llvm) are resolved. This ensures that
CLANG_INSTALL_PREFIX ends up to be /usr/lib/llvm-X.Y instead of /usr.

Partially addresses PR37128

Diff Detail

Event Timeline

Lekensteyn created this revision.May 7 2018, 6:00 AM

Hi, this patch was required to make find_package(Clang CONFIG) work when /usr/lib/llvm/clang-X.Y was a symlink and is integrated in the Debian packaging. Please have a look, thanks!

One unfortunate limitation (that existed before) is that find_package(Clang 5.0) does not work because CLANG_VERSION_* is not defined. So
find_package(LLVM 6.0) could locate /usr/lib/cmake/llvm-6.0/LLVMConfig.cmake but then
find_package(Clang) could end up using /usr/lib/cmake/clang-5.0. (This was discovered while testing a Clang 6.0 build on a system with Clang 5.0 co-installed.)

The reason for me to use different Clang versions is for CI purposes. As such, I am currently using CMAKE_PREFIX_PATH=/usr/lib/llvm-6.0 which will find the correct version without explicitly having to specify it in find_package.

Lekensteyn abandoned this revision.May 9 2018, 1:43 AM

Per discussion in D46521, resolving symlinks might introduce issues that are are worse than the issue that was solved here. It seems better to carry this patch downstream (in Debian) since the problem only exists there due to its use of symlinks (which is apparently not fully supported/recommended in LLVM upstream).

kimgr added a subscriber: kimgr.EditedMay 12 2018, 1:06 AM

I'm interested in this, I've tried for a while to fix the Debian packaging but I'm completely new to the packaging toolchain, so I'm making slow headway.

Some of the problems are recorded in: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=862328

My (possibly naive) take is that since the LLVM/Clang build/install tree works as-is with find_package, the bug must be in packaging. That is, if you have a local build tree in /build/, this configures without a hitch: cmake -DCMAKE_PREFIX_PATH=/build/ -G Ninja . with a simple CMakeLists.txt doing find_package for both LLVM and Clang.

I'm interested in this, I've tried for a while to fix the Debian packaging but I'm completely new to the packaging toolchain, so I'm making slow headway.

The Debian clang-5.0 1:5.0.2-2 package already includes this patch. I tried to upstream it, but there were some concerns about the real path not always being the desired value.

My (possibly naive) take is that since the LLVM/Clang build/install tree works as-is with find_package, the bug must be in packaging. That is, if you have a local build tree in /build/, this configures without a hitch: cmake -DCMAKE_PREFIX_PATH=/build/ -G Ninja . with a simple CMakeLists.txt doing find_package for both LLVM and Clang.

On Debian, cmake -DCMAKE_PREFIX_PATH=/usr/lib/llvm-5.0 would work as well, the problem was that the FindClang.cmake file was installed into an unexpected location (packaging issue).

Secondary to that, some additional symlinks were installed to ensure that users do not have to set CMAKE_PREFIX_PATH in order to find some LLVM/Clang version. That scenario was being addressed with this patch (and D46521).

kimgr added a comment.May 12 2018, 2:20 AM

It works! Having to specify CMAKE_PREFIX_PATH is at least documentable, so I don't see that as a major drawback, especially if it makes docs for tools using Clang more portable.

Thank you for moving this along, now I can vastly simplify our CMake build.