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 C577915815E for ; Mon, 5 Feb 2024 23:46:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B85A5E2A7F; Mon, 5 Feb 2024 23:46:20 +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)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 54AD6E2A30 for ; Mon, 5 Feb 2024 23:46:20 +0000 (UTC) References: <211397b1e89bc0d47a1769102648350a3336f9a5.camel@gentoo.org> User-agent: mu4e 1.10.8; emacs 30.0.50 From: Sam James To: gentoo-dev@lists.gentoo.org Cc: darkdefende@gmail.com Subject: Re: [gentoo-dev] [RFC] Introducing LLVM_TARGET Date: Mon, 05 Feb 2024 23:44:37 +0000 Organization: Gentoo In-reply-to: <211397b1e89bc0d47a1769102648350a3336f9a5.camel@gentoo.org> Message-ID: <87il328ofr.fsf@gentoo.org> 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: quoted-printable X-Archives-Salt: f0a9c452-55ca-4ed1-9e29-56bda4363507 X-Archives-Hash: 30004a200e282a8aae044d3f6e2c0e5a Micha=C5=82 G=C3=B3rny writes: > [[PGP Signed Part:Undecided]] > Hi, > > TL;DR: Given that (not really surprising) the current approach for LLVM > dependencies doesn't work, I think it's time to give up and introduce > LLVM_TARGETS. This would probably mean introduce llvm-r1.eclass. > > However, since random apps tend to require old versions of LLVM, I do > wonder if we should set the default value globally, or have the eclass > generate IUSE defaults, so that everything works out of the box. > I need to think about this bit. > > The problem roughly is that right now we rely on depstrings like: > > DEPEND=3D" > || ( > ( sys-devel/clang:18 sys-devel/llvm:18 ) > ( sys-devel/clang:17 sys-devel/llvm:17 ) > ( sys-devel/clang:16 sys-devel/llvm:16 ) > ) > " > > This kinda works, in the sense that it will enforce that you have > a single matching version of LLVM+Clang, and the eclass will use it.=20 > However, the :=3D deps on top may be entirely mismatched. For example, if > you have llvm:18 and clang:17 (+ llvm:17) installed, you'd get: > > sys-devel/clang:17=3D > sys-devel/llvm:18=3D > > When more packages land on the list, this could lead to quite a mess. > > So what'd we go for would effectively be: > > DEPEND=3D" > llvm_target_16? ( sys-devel/clang:16 sys-devel/llvm:16 ) > llvm_target_17? ( sys-devel/clang:17 sys-devel/llvm:17 ) > llvm_target_18? ( sys-devel/clang:18 sys-devel/llvm:18 ) > " > > WDYT? We should mention that https://bugs.gentoo.org/923228 was the motivation that tipped us over the edge here. We should also consider the https://bugs.gentoo.org/880671 / https://bugs.gentoo.org/821955 case, as I think this is going to end up solving that too, actually. But yeah, I like it. It solves a request we've had from users for a while ("let me choose") and it solves these silly dep games. Thank you!