[llvm-dev] llvm-config deprecation

[Andrew Kelley via llvm-dev]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190101/17fecf41/attachment.sig>