llvm dev - Jan 2019 - llvm-config deprecation

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>