<div dir="ltr">Not sure why you're getting the CMake error, but we aren't deprecating `llvm-config` that I know of.<div><br></div><div>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`.</div><div><br></div><div>Much as your email explain, there are many (non-CMake) users of `llvm-config` and it would be strange for it to go away.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 1, 2019 at 2:34 PM Andrew Kelley via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My build process:<br>
<br>
$ cd llvm/<br>
$ mkdir build<br>
$ cd build<br>
$ cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/local<br>
-DCMAKE_PREFIX_PATH=$HOME/local -DCMAKE_BUILD_TYPE=Release<br>
-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="WebAssembly;AVR;RISCV"<br>
-DLLVM_ENABLE_LIBXML2=OFF<br>
$ make install<br>
<br>
$ cd clang/<br>
$ mkdir build<br>
$ cd build<br>
$ cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/local<br>
-DCMAKE_PREFIX_PATH=$HOME/local -DCMAKE_BUILD_TYPE=Release<br>
$ make install<br>
<br>
This is trunk. When I do this, I get the following warning:<br>
<br>
-- Found LLVM_CONFIG as $HOME/local/bin/llvm-config<br>
CMake Deprecation Warning at CMakeLists.txt:17 (message):<br>
  Using llvm-config to detect the LLVM installation is deprecated.  The<br>
  installed cmake files should be used instead.  CMake should be able to<br>
  detect your LLVM install automatically, but you can also use LLVM_DIR to<br>
  specify the path containing LLVMConfig.cmake.<br>
<br>
<br>
It seems that LLVM is giving a warning for its own build process here.<br>
I'm concerned about this being deprecated, for several reasons:<br>
<br>
 * Distributing the source tarballs for Clang and LLVM separately and<br>
supporting a build process that mirrors how it will work for system<br>
package managers is desirable. The thing that some developers do by<br>
copying different projects all into the LLVM project subfolder is<br>
understandable if it has benefits, but is non-standard across the wider<br>
ecosystem, and should not be considered the canonical way to build, let<br>
alone the only way to build.<br>
<br>
 * Removing llvm-config introduces a requirement on projects to use<br>
CMake as a build system if they want to link against LLVM. While CMake<br>
is widely used, it is unwise and unnecessary to force projects to depend<br>
on it. As an example use case, the Zig self-hosted compiler works great<br>
on many platforms, using llvm-config to find the location of LLVM<br>
libraries. However, the build process of the self-hosted compiler does<br>
not use CMake, and being forced to use CMake would be a severe downgrade<br>
from the self-hosted build system.<br>
<br>
 * There is no other declarative way to find out where all the LLVM<br>
libraries are installed. A simple text file, or a package definition,<br>
would be a welcome alternative to llvm-config.<br>
<br>
I hope this feedback is useful to the LLVM core developers, and I hope<br>
we can come up with a better system that accomplishes the goals of<br>
deprecating llvm-config as well as my goals stated above as a downstream<br>
project.<br>
<br>
Regards,<br>
Andrew<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>