[PATCH] D46521: [llvm] cmake: resolve symlinks in LLVMConfig.cmake

[Peter Wu via Phabricator via llvm-commits]

Lekensteyn added a comment.

To support multiple co-installed versions, Debian/Ubuntu use /usr/lib/llvm-X.Y as prefix instead of /usr. It is however desirable to make one of these versions available to CMake by default and that requires only one symlink per project (LLVM/Clang): `/usr/lib/llvm-X.Y/cmake` -> `/usr/lib/llvm-X.Y/lib/cmake/llvm`.
This symlink however requires that the `LLVMConfig.cmake` script uses its real path to locate other files. The alternative is to require every user to set `CMAKE_PREFIX_PATH` which in my opinion is unreasonable to ask.

Distributions that do not use this approach include Fedora and Arch Linux. They use `/usr` as prefix for the latest version (so LLVMConfig.cmake can be found in `/usr/lib/cmake/llvm/` as expected by CMake). For older versions, they use a different prefix, `/usr/lib/llvm-X.Y`.

As a user, I really like the standarized /usr/lib/llvm-X.Y structure (as used by apt.llvm.org) since it makes CI integration with multiple versions easier (set `CMAKE_PREFIX_PATH=/usr/lib/llvm-$VERSION` without special cases).
Installing everything in `/usr/lib/llvm-X.Y` has the additional benefit that upgrades are less likely to break things and requires less downloads:

- Initially "clang" depends on "clang-5.0" which installs to /usr/lib/llvm-5.0.
- Another package (say, mesa) is installed which depends on clang 5.0.
- Later, a new LLVM version is released and "clang" depends on "clang-6.0".
- Since the old package still depends on "clang-5.0", it keeps working.

If the second approach is used, then this would be the "upgrade" path:

- Install "clang" which installs to /usr
- Another package (say, mesa) is installed which depends on this Clang version.
- Later, a newer LLVM version is released.
- To upgrade the "clang" package and keep "mesa" working, these are the options:
  - Rebuild "mesa" with the latest clang, upgrade both. (Works only if mesa is actually compatible with the latest LLVM version.)
  - Build a new "clang5.0" package, rebuild mesa to use it. Upgrade clang, mesa and install a new "clang5.0" package. Wastes CPU cycles and data because "clang5.0" is essentially the same as the old "clang", except that files are now in /usr/lib/llvm-5.0.

Given this scenario, I think that the Debian approach is more beneficial if stability/backwards compatibility is important. And the only cost for this is supporting adding a few symlinks in /usr/bin and one in /usr/lib/cmake. Does that seem unreasonable to you? Why do you think that this (installing to /usr/lib/llvm-X.Y?) is broken by design?


Repository:
  rL LLVM

https://reviews.llvm.org/D46521