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>
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>
On 1/1/19 10:00 PM, Chandler Carruth wrote:> 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.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 -------------- 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/b21362b6/attachment.sig>
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
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/20190102/c681bef3/attachment.html>