llvm-config deprecation

Project Infrastructure LLVM Dev List Archives
1

My build process:

$ cd llvm/
$ mkdir build
$ cd build
$ cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/local
-DCMAKE_PREFIX_PATH=$HOME/local -DCMAKE_BUILD_TYPE=Release
-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="WebAssembly;AVR;RISCV"
-DLLVM_ENABLE_LIBXML2=OFF
$ make install

$ cd clang/
$ mkdir build
$ cd build
$ cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/local
-DCMAKE_PREFIX_PATH=$HOME/local -DCMAKE_BUILD_TYPE=Release
$ make install

This is trunk. When I do this, I get the following warning:

-- Found LLVM_CONFIG as $HOME/local/bin/llvm-config
CMake Deprecation Warning at CMakeLists.txt:17 (message):
  Using llvm-config to detect the LLVM installation is deprecated. The
  installed cmake files should be used instead. CMake should be able to
  detect your LLVM install automatically, but you can also use LLVM_DIR to
  specify the path containing LLVMConfig.cmake.

It seems that LLVM is giving a warning for its own build process here.
I'm concerned about this being deprecated, for several reasons:

* Distributing the source tarballs for Clang and LLVM separately and
supporting a build process that mirrors how it will work for system
package managers is desirable. The thing that some developers do by
copying different projects all into the LLVM project subfolder is
understandable if it has benefits, but is non-standard across the wider
ecosystem, and should not be considered the canonical way to build, let
alone the only way to build.

* Removing llvm-config introduces a requirement on projects to use
CMake as a build system if they want to link against LLVM. While CMake
is widely used, it is unwise and unnecessary to force projects to depend
on it. As an example use case, the Zig self-hosted compiler works great
on many platforms, using llvm-config to find the location of LLVM
libraries. However, the build process of the self-hosted compiler does
not use CMake, and being forced to use CMake would be a severe downgrade
from the self-hosted build system.

* There is no other declarative way to find out where all the LLVM
libraries are installed. A simple text file, or a package definition,
would be a welcome alternative to llvm-config.

I hope this feedback is useful to the LLVM core developers, and I hope
we can come up with a better system that accomplishes the goals of
deprecating llvm-config as well as my goals stated above as a downstream
project.

Regards,
Andrew

2

Not sure why you’re getting the CMake error, but we aren’t deprecating llvm-config that I know of.

The message you’re seeing is about deprecating the use of llvm-config from CMake. There, we are providing installed CMake fragments that we want people to use instead of relying on the generic foo-config support in CMake combined with llvm-config.

Much as your email explain, there are many (non-CMake) users of llvm-config and it would be strange for it to go away.

3

Thanks for the clarification. In this case, all is well. I believe that
what I am observing is the "out-of-tree" build process, where LLVM and
Clang are installed via separate source tarballs, which produces this
warning. I do think that it would be beneficial to improve the wording
of the warning to clarify that llvm-config is not deprecated, as well as
to fix "out of tree" build to not produce the warning - since this
message would be displayed for package managers such as Debian when
building Clang for the system, and this is likely to cause confusion.

Regards,
Andrew

4

Hi Andrew,

I’ve never built Clang out of the LLVM tree, if it’s present in the LLVM tree at build time, it’s just built.

Did you try passing in the config path, like this:

-DLLVM_CONFIG_PATH=${TOOLCHAIN_DIR}/bin/llvm-config

Regarding the file list, in the root of your build folder, install_manifest.txt has all the files. This file is commonly used to create an “uninstall” target.

Joel