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 (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B4B3315815E for ; Wed, 7 Feb 2024 20:35:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C8F38E29DA; Wed, 7 Feb 2024 20:35:24 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (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 76DFCE29CB for ; Wed, 7 Feb 2024 20:35:24 +0000 (UTC) From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Cc: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= Subject: [gentoo-dev] [PATCH 0/8] llvm-r1.eclass + llvm-utils.eclass: new eclasses to sort out LLVM mess Date: Wed, 7 Feb 2024 21:11:35 +0100 Message-ID: <20240207203515.17640-1-mgorny@gentoo.org> X-Mailer: git-send-email 2.43.0 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: f4fe532f-0371-4ec4-b900-c661b48bec40 X-Archives-Hash: ec51b6268fc95b5fe261e3ec64ae72e8 Hi, TL;DR: here's a series of patches adding llvm-r1.eclass that tries to sort out LLVM dependency mess via using USE_EXPAND flags LLVM_SLOT. Roughly, the problems with LLVM are that: 1. Every half a year there's a major release that's doing major breaking API changes. 2. Reverse dependencies are usually slow to adapt. 3. Often multiple packages in a depchain end up linking to LLVM, and you really shouldn't link more than one version at a time. Because of the first two, we've started slotting LLVM. However, our current approach of combining || blocks with := deps turned out to be messy. It is inconvenient, it can't properly dep on two leaf LLVM packages and it can't enforce linked slot match. So I've figured out it's time to give in and switch to a USE flag-based approach. Funny enough, this makes both the eclass and the ebuilds using it simpler. This patch series does, in order: 1. Split out a llvm-utils.eclass that carries code from llvm.eclass that will be shared by llvm-r1.eclass, but also used by some LLVM ebuilds directly (they currently depend on llvm.eclass but they don't really need to). This also involves splitting out the PATH mangling logic, fixing it and adding more tests for all the functions. 2. Add a USE_EXPAND="LLVM_SLOT" along with some initial masks. We'll probably need to play with masks a bit more before llvm-r1.eclass is used in stable ebuilds. 3. Add a llvm-r1.eclass. More design details below. 4. Convert some example ebuilds to the new eclasses. The new eclass uses an approach that's a hybrid between python-single-r1 and slots. It expects LLVM_COMPAT to declare supported LLVM versions, and gives llvm_gen_dep to depend on slotted packages, and LLVM_USEDEP to depend on non-slotted packages. It sets IUSE, REQUIRED_USE and exports pkg_setup() that takes care of tool adjustment and setting PATH, similarly to what the old eclass did -- except it uses whatever LLVM_SLOT was selected by the user rather than using a horribly convoluted logic to guess one. One original idea is that we don't set default LLVM_SLOT in profiles. Instead, the eclass uses IUSE defaults to select the "newest stable" slot that's supported by the package. The rationale is that we have too wide a span of LLVM versions supported by various packages to be able to conveniently select just one. A rough idea of how an ebuild using the eclass could look like: LLVM_COMPAT=( {15..18} ) inherit llvm-r1 IUSE="llvm" DEPEND=" llvm? ( dev-libs/my-dependency[${LLVM_USEDEP}] $(llvm_gen_dep ' sys-devel/clang:${LLVM_SLOT} sys-devel/llvm:${LLVM_SLOT} ') ) " pkg_setup() { use llvm && llvm-r1_pkg_setup } src_configure() { econf --if-path-doesnt-work="$(get_llvm_prefix)" } Michał Górny (8): llvm-utils.eclass: Introduce an eclass for common helpers llvm-utils.eclass: Split out PATH prepending logic llvm-utils.eclass: Fix llvm_prepend_path to avoid duplicates profiles: Introduce LLVM_SLOT USE_EXPAND variable llvm-r1.eclass: Initial version dev-util/intel_clc: Migrate to llvm-r1 media-libs/mesa: Migrate to llvm-r1 sys-devel/lld: Migrate to llvm-utils.eclass dev-util/intel_clc/intel_clc-24.0.0.ebuild | 48 +---- dev-util/intel_clc/intel_clc-9999.ebuild | 48 +---- eclass/llvm-r1.eclass | 226 ++++++++++++++++++++ eclass/llvm-utils.eclass | 151 +++++++++++++ eclass/llvm.eclass | 117 +--------- eclass/tests/llvm-r1.sh | 151 +++++++++++++ eclass/tests/llvm-utils.sh | 112 ++++++++++ media-libs/mesa/mesa-24.0.0.ebuild | 53 +---- media-libs/mesa/mesa-9999.ebuild | 53 +---- profiles/arch/base/use.mask | 5 + profiles/arch/loong/use.mask | 6 +- profiles/base/make.defaults | 2 +- profiles/desc/llvm_slot.desc | 8 + profiles/embedded/make.defaults | 4 +- sys-devel/lld/lld-18.1.0_rc2.ebuild | 5 +- sys-devel/lld/lld-19.0.0.9999.ebuild | 5 +- sys-devel/lld/lld-19.0.0_pre20240203.ebuild | 5 +- 17 files changed, 714 insertions(+), 285 deletions(-) create mode 100644 eclass/llvm-r1.eclass create mode 100644 eclass/llvm-utils.eclass create mode 100755 eclass/tests/llvm-r1.sh create mode 100755 eclass/tests/llvm-utils.sh create mode 100644 profiles/desc/llvm_slot.desc -- 2.43.0