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. :)
signature.asc
Description: This is a digitally signed message part
