[gentoo-user] Is there a reason why LLVM/Clang ebuilds don't support "mutislot"?

[gentoo-user] Is there a reason why LLVM/Clang ebuilds don't support "mutislot"?

[P Levine]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

Other distros like Ubuntu support the installation of multiple versions of
LLVM/Clang side by side.  One of the things Clang is really good at is
support for the most recently approved upcoming features of the C++17
standard.  The best support for testing such features is with the latest
sys-devel/llvm-9999.  However if I want to compile Mesa against a stable
version LLVM/Clang as well, I don't get that option.

[-- Attachment #2: Type: text/html, Size: 607 bytes --]

Re: [gentoo-user] Is there a reason why LLVM/Clang ebuilds don't support "mutislot"?

[Deven Lahoti]

[-- Attachment #1: Type: text/plain, Size: 122 bytes --]

This also makes it difficult to use GHC's LLVM backend, since its
compatible versions usually lag behind the current one.

[-- Attachment #2: Type: text/html, Size: 144 bytes --]

Re: [gentoo-user] Is there a reason why LLVM/Clang ebuilds don't support "mutislot"?

[Jeremi Piotrowski]

On Sun, Aug 28, 2016 at 11:58:03PM -0400, P Levine wrote:
> Other distros like Ubuntu support the installation of multiple versions of
> LLVM/Clang side by side.  One of the things Clang is really good at is
> support for the most recently approved upcoming features of the C++17
> standard.  The best support for testing such features is with the latest
> sys-devel/llvm-9999.  However if I want to compile Mesa against a stable
> version LLVM/Clang as well, I don't get that option.

I'm not sure such a configuration is fully supported upstream, but the way
ubuntu (and debian) does this is (was?) painfully broken. If I recall correctly
they first build it in one location and then move it around and try to
partially solve things through symlinks.

This totally destroys llvm-config and LLVM's cmake find_package module
meaning those things have hard-coded paths that have nothing to do with
where the things are installed on the system. Simple example, the
following CMakeLists.txt

    cmake_minimum_required(VERSION 3.4)
    project(llvm-test)

    find_package(LLVM)

errors out on ubuntu with:

    CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:178 (include):
      include could not find load file:

        /usr/share/llvm/cmake/LLVMExports.cmake
    Call Stack (most recent call first):
      CMakeLists.txt:4 (find_package)


    CMake Error at /usr/share/llvm-3.8/cmake/LLVMConfig.cmake:181 (include):
      include could not find load file:

        /usr/share/llvm/cmake/LLVM-Config.cmake
    Call Stack (most recent call first):
      CMakeLists.txt:4 (find_package)


    -- Configuring incomplete, errors occurred!

Fixing this one path leads to more suffering further down the road.

The way gentoo maintainers package LLVM is much saner and developer friendly.