From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9395B1581F3 for ; Tue, 3 Dec 2024 16:29:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 20517E08D1; Tue, 3 Dec 2024 16:29:45 +0000 (UTC) Received: from flump.de (flump.de [185.163.118.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BB215E086F for ; Tue, 3 Dec 2024 16:29:44 +0000 (UTC) Received: from falbala.localnet (ip4d1725e8.dynamic.kabel-deutschland.de [77.23.37.232]) by flump.de (Postfix) with ESMTPSA id 3EE2D1C50FF4 for ; Tue, 03 Dec 2024 17:29:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=flump.de; s=mail; t=1733243383; bh=web40w+eCbGqF/0d0wCcA482uJ3wr+idWzTw04pDZE4=; h=From:To:Subject:Date:In-Reply-To:References; b=vyAfO0EhzSzYz+HUv4P8qr0sVrvyFfc1wAt4Yz2wu08BOOfDyLCBX9zQQDvsQVbpo JYvZeTWFoMx5LIH++1pHtuKaURvDq3Z955JuSbz27i++JLlxKVByirWybbqau/QrcY 2u5gMYlS2rUkEqaMZipE9Nu0ey2FXUsTD56ZEZ30= From: Gerion Entrup To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Future changes to LLVM eclasses (or how do you use LLVM?) Date: Tue, 03 Dec 2024 17:29:39 +0100 Message-ID: <2065355.yKVeVyVuyW@falbala> In-Reply-To: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2237383.OBFZWjSADL"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Archives-Salt: 312b8f59-d319-49b1-834e-7326e64748fa X-Archives-Hash: bedddf4042788db05c17ee769afcc2ae --nextPart2237383.OBFZWjSADL Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Gerion Entrup To: gentoo-dev@lists.gentoo.org Date: Tue, 03 Dec 2024 17:29:39 +0100 Message-ID: <2065355.yKVeVyVuyW@falbala> MIME-Version: 1.0 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-.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/9a3570017a8a61cf078ed5142= d272ed279f8d112/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=3D41794 Am Dienstag, 3. Dezember 2024, 16:32:45 MEZ schrieb Micha=C5=82 G=C3=B3rny: > Hello, >=20 > 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. >=20 >=20 > Background > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 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. >=20 > When I added EAPI 7 support, I went for prepending the following thing > to PATH: >=20 > ${ESYSROOT}/usr/lib/llvm/.../bin >=20 > 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: >=20 > 1. Relying on a fancy CMake behavior of locating CMake files relative to > PATH, and >=20 > 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. >=20 > So what we're really doing is implicitly telling CMake to use: >=20 > ${ESYSROOT}/usr/lib/llvm/.../lib*/cmake >=20 > 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=3Dclang, 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. >=20 > 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. >=20 >=20 > Future options > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Some of the options that already popped up during discussions include: >=20 > 1. Stopping to export pkg_setup() entirely, and expecting people to > explicitly pass the LLVM path to the build system, e.g. something like: >=20 > -DLLVM_CMAKE_PATH=3D"$(get_llvm_prefix -d)" >=20 > 2. Setting specific environment variables (such as LLVM_ROOT, CLANG_ROOT > and so on for CMake, or perhaps CMAKE_PREFIX_PATH). >=20 > 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). >=20 > Any other ideas? How does your package select LLVM version, and which > of these options would work best for you? >=20 >=20 >=20 --nextPart2237383.OBFZWjSADL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEEM/tVN9WpYYHnPZHxloeAdSYJHeoFAmdPMfMACgkQloeAdSYJ HersLwwAkiD2zXOn9Ke/C1+D+11Jfo0RfCSGMOytEKkbYCHvhkF/BxC1458chVEp saMzvR+zxH52rxbZlUFwwS8TEqKb6hluyCj4OOVC8gTPnWzja6Z4tsi5i8AXeE6u V9AVKDAWywbAU4vh3EBzaTZEYSBagXoh1lQ/4rbrs9padgIAyf6J8c0xUCD1zPvC 79VakF+PsKLLBv6L7mMlezIIOLqXXVBclNyltxxmsQN6E2kXWiubjJusu1WMOzZg /sDfqdOg4iuMl4emOpg0BaJG2kdzZckfv3vO4GhvtBp2CpysW9YyENnoTrWn1EzI q4Yarr9spsmJQHTubq8wkKiYfW4cp200uK8Jue43/j8zegrER0sKm03mUsUVTUey RxQ5HlXuPuRUc/jXWN0Z5w7SlIFPQZs1dKCjqUUalbGtRMaef+MxUwdOaoeHpB99 2fBLqaOvoMA433aBDKEaH352YEyp/hQUvI8IFeRQddt389zYom8ThTKIyGWvysbu TrzNtHvt =tsyW -----END PGP SIGNATURE----- --nextPart2237383.OBFZWjSADL--