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