Re: [gentoo-dev] [RFC] Future changes to LLVM eclasses (or how do you use LLVM?)

[James Le Cuirot <chewi@gentoo.org>]

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

On Tue, 2024-12-03 at 16:32 +0100, Michał Górny wrote:
> Hello,
> 
> TL;DR: the way llvm/llvm-r1 eclasses currently mangle PATH is broken,
> and I'd like to replace that with something better (possibly in llvm-
> r2.eclass, given how fragile this thing is).  So I'd like to discuss
> potential "better" solutions -- and particularly ask you what your LLVM-
> using packages need.
> 
> 
> Background
> ==========
> 
> The current logic goes way back to llvm.eclass, and EAPIs that did not
> have native cross-build support.  Back then, prepending the slotted LLVM
> bindir to PATH was the obvious way of getting software to find the right
> LLVM version.
> 
> When I added EAPI 7 support, I went for prepending the following thing
> to PATH:
> 
>   ${ESYSROOT}/usr/lib/llvm/.../bin
> 
> People doing cross will clearly notice the mistake here -- it's using
> binaries from ESYSROOT rather than BROOT!  Except it's not a mistake,
> but an ugly hack.  What we're doing here is:
> 
> 1. Relying on a fancy CMake behavior of locating CMake files relative to
> PATH, and
> 
> 2. Relying on the package either not caring about LLVM executables or
> the system not being able to execute the executables in ESYSROOT
> and gracefully falling back to other locations in PATH.
> 
> So what we're really doing is implicitly telling CMake to use:
> 
>   ${ESYSROOT}/usr/lib/llvm/.../lib*/cmake
> 
> Yes, it's awful.  And yes, it already did backfire in the past, so I've
> ended up adding quite a complex logic to prevent these path
> manipulations from overriding the toolchain set by user.  For example,
> if the user has CC=clang, that normally evalutes to clang-19, we now
> adjust CC so that it suddenly doesn't switch to clang-17 because
> the package uses libLLVM-17.  Meh.
> 
> When working on llvm-r1, I've focused on the more immediate problem of
> horribly complex and broken package dependencies, and forgot about this.
> I've only recalled the problem during the initial rust.eclass reviews,
> since it happened to copy that incorrect logic.
> 
> 
> Future options
> ==============
> 
> Some of the options that already popped up during discussions include:
> 
> 1. Stopping to export pkg_setup() entirely, and expecting people to
> explicitly pass the LLVM path to the build system, e.g. something like:
> 
>   -DLLVM_CMAKE_PATH="$(get_llvm_prefix -d)"
> 
> 2. Setting specific environment variables (such as LLVM_ROOT, CLANG_ROOT
> and so on for CMake, or perhaps CMAKE_PREFIX_PATH).
> 
> 3. Creating a minimal llvm-config wrapper in ${T}, and adding it to
> ${PATH} instead of the whole LLVM tree.  Note that we'd need to write
> our own since llvm-config is an executable, so we can't run the one from
> ESYSROOT, and we can't rely on BROOT having a match (or don't want to
> force a second copy of LLVM unnecessarily).
> 
> Any other ideas?  How does your package select LLVM version, and which
> of these options would work best for you?

I did some up with something similar to #3 back in 2019, but you were so dead
against it that I threw that work away. It wrapped around BROOT's llvm-config,
which you don't want to do, but that didn't seem to be the part you had a
problem with. Doing it that way would be easier, and maybe not such a big deal
since you need BROOT to having a matching slot to build LLVM in the first
place. Writing something based around pkg-config would be nicer though. I'd be
happy with either. I might even be able to help out. :)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 858 bytes --]