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

["Michał Górny" <mgorny@gentoo.org>]

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

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?


-- 
Best regards,
Michał Górny


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