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 E64381581F3 for ; Tue, 3 Dec 2024 15:32:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F2FDEE086A; Tue, 3 Dec 2024 15:32:51 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 BAE8EE0856 for ; Tue, 3 Dec 2024 15:32:51 +0000 (UTC) Message-ID: Subject: [gentoo-dev] [RFC] Future changes to LLVM eclasses (or how do you use LLVM?) From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Tue, 03 Dec 2024 16:32:45 +0100 Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-okjvoR8h+kPnov/+KMJ6" User-Agent: Evolution 3.52.4 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 X-Archives-Salt: 88d6ae9e-bcbc-4706-aafd-0c9d4020c9cd X-Archives-Hash: cd843dfb6a053ad1f70d670f8ad3a3ab --=-okjvoR8h+kPnov/+KMJ6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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=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. 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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=3D"$(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? --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-okjvoR8h+kPnov/+KMJ6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmdPJJ0SHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOVGkH/0wJGS1ZHMg4IxEPzeRLtGw/6p/SjuDu QuD3ixOsS4xiPwbdZay4J0D4A+tCpQjhxWYEZM+eLy5J8XPpJpkm61wfUBLD347+ eES3znrMaO3mEX54FjQuwBz6Fjbtg1JbVWbAhsEQlEWbq0avr2vNumUxVuD3KzM4 ligDxmVIr8s26i2jksYPSnRtNCkNGwoKiQxcW5i08lVcJ5Q14sSgCPuZoltwg/Zk 2fPGKRefst2/DKhSUCaA8rMcAVaNj/24lTr9lUJwc7a9bOP2aN0N1AIA+RmqkRyz mY1Pr4eGUepOYE/persvSogTAcRFY4nzRvHpA+FUERcLafq4hlT9SHA= =ywro -----END PGP SIGNATURE----- --=-okjvoR8h+kPnov/+KMJ6--