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

[Gerion Entrup <gerion.entrup@flump.de>]

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

Hi,

this is not from a Gentoo packaging perspective but from a developer
perspective that needs to compile with and against LLVM on several
distributions. For building a package against LLVM, LLVM offers two
possibilities: llvm-config and their CMake files. I only have experience
with the first one. LLVM furthermore does not offer a consistent way to
install their binaries (including llvm-config) in different versions, so
most Linux distributions does that in a different way.

Therefore, we needed to find a way to tell the build system itself,
how to manage this. In a concrete example, we are doing this for ARA/PARROT
here [1] (see the native-<distribution>.ini files). Meson is made aware
of the path to llvm-config with a distribution specific config file.
Then Meson discovers other binaries with the help of llvm-config [2, 3].
Overall, this works well but needs work per distribution.

Here is a Meson bug that I created to classify the solutions of
different Linux distributions [4]. I also created a Gentoo bug for it
some time ago (were you recommended for an upstream fix) [5]. Here is the
old LLVM bug for the same problem (I do not know if they transferred
it to Github) [6].

I have no clear solution to the problem. I wish that LLVM itself would
create versioned symlinks to all of their binary tools that distribution
could install in /usr/bin and build systems can use to find specific
versions of LLVM libraries.

Kind regards
Gerion

[1] https://github.com/luhsra/PARROT
[2] https://github.com/luhsra/ara-toolchains/blob/9a3570017a8a61cf078ed5142d272ed279f8d112/meson.build#L10
[3] https://mesonbuild.com/Dependencies.html#llvm
[4] https://github.com/mesonbuild/meson/issues/5370
[5] https://bugs.gentoo.org/677504
[5] https://bugs.llvm.org/show_bug.cgi?id=41794

Am Dienstag, 3. Dezember 2024, 16:32:45 MEZ schrieb Michał Górny:
> 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?
> 
> 
> 


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