CMake: Deprecate using llvm-config to detect llvm installation


CMake: Deprecate using llvm-config to detect llvm installation

clang currently uses llvm-config to determine the installation paths
for llvm's headers and binaries. clang is also using LLVM's cmake
files to determine other information about the LLVM build, like
LLVM_LIBDIR_SUFFIX, LLVM_VERSION_*, etc. Since the installation
paths are also available via the cmake files, we can simplify the code
by only relying on information from cmake about the LLVM install and
dropping the use of llvm-config altogether.

In addition to simplifying the code, the cmake files have more
accurate information about the llvm installation paths. llvm-config
assumes that the lib, bin, and cmake directories are always located
in the same place relative to the path of the llvm-config executable.
This can be wrong if a user decides to install headers, binaries
or libraries to a non-standard location: e.g. static libraries
installed to /usr/lib/llvm6.0/

This patch takes the first step towards dropping llvm-config by
removing the automatic detection of llvm-config (users can still
manually supply a path to llvm-config by passing
-DLLVM_CONFIG=/usr/bin/llvm-config to cmake) and adding a
deprecation warning when users try to use this option.

Reviewers: chandlerc, beanz, mgorny, chapuni

Subscribers: mehdi_amini, dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D51714


tstellarNov 12 2018, 7:42 PM
Differential Revision
D51714: CMake: Deprecate using llvm-config to detect llvm installation
rL346731: CMake: Replace open-coded find_package

Event Timeline

It's not clear from this whether there's a plan to remove llvm-config, or just to remove llvm-config as a way for clang to detect llvm. I would be strongly opposed to the former. Having tried to maintain out-of-tree code that builds with multiple versions of LLVM, it is more or less possible with llvm-config and totally impossible with the LLVM CMake files. Unless dropping llvm-config is accompanied by a strong commitment to long-term API stability for the LLVM CMake infrastructure, this would have a significant negative impact on downstream consumers of LLVM (and, even then, extracting the CMake information when your downstream build system is not CMake is painful).

My idea was to stop using llvm-config during the clang (and other sub-project) builds only. I don't have any plans to remove the llvm-config tool from llvm.