[llvm-dev] llvm-config deprecation

[Chandler Carruth via llvm-dev]

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.

On Tue, Jan 1, 2019 at 2:34 PM Andrew Kelley via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190101/9ecfab49/attachment.html>