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.


The problem roughly is that right now we rely on depstrings like:

DEPEND="
<sys-devel/clang-19:=
<sys-devel/llvm-19:=
|| (
( 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.
However, the := 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=
sys-devel/llvm:18=

When more packages land on the list, this could lead to quite a mess.

So what'd we go for would effectively be:

DEPEND="
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?

--
Best regards,
Michał Górny


-----BEGIN PGP SIGNATURE-----

iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmXBFbQSHG1nb3JueUBn ZW50b28ub3JnAAoJEGOa2uIyniQOzoYIAJXKm77fc9qEF+KEaZOEcjifyKuqYSO/ ur+X1ytxh0NSPwoqS1uHWB3U8Rl9G567s3LAq3YEkSLMwVxgFBUnmEFbniikspYN KuPCEiTK9EP5Eu752TY+7SXqEgxt5GaHttF/WIS13pKyyiL+sDnS9/2QWabePMFy R3N336JuFTd8ojLmU+9FLF+0fHNJm7EVlT4Gcm09k1l4ihKsW/9AV9TKMVqe2O+I 0MOcaIK50gZZcUd3b7yuzavrBhaXgln1cVNJ7ujEehpzfZecJh0bTmplUxK0lsZx HFryxhMbJ8KGA8BH7oPUWjJlJwaZFKZ3LwjrYxNtQzo2bNLa7+rz8vA=
=Djbi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sam James <sam@gentoo.org> writes:

Michał Górny <mgorny@gentoo.org> 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="
<sys-devel/clang-19:=
<sys-devel/llvm-19:=
|| (
( 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.
However, the := 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=
sys-devel/llvm:18=

When more packages land on the list, this could lead to quite a mess.

So what'd we go for would effectively be:

DEPEND="
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.

I suppose it will fix https://bugs.gentoo.org/919150 for us too.

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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michał Górny <mgorny@gentoo.org> 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="
<sys-devel/clang-19:=
<sys-devel/llvm-19:=
|| (
( 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. However, the := 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=
sys-devel/llvm:18=

When more packages land on the list, this could lead to quite a mess.

So what'd we go for would effectively be:

DEPEND="
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!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Feb 05, 2024 at 11:44:37PM +0000, Sam James wrote:>

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.

*Was* thinking about how it would be unnecessary machinery to implement
if we ever give up and switch to a monorepo ebuild, but had slipped my
mind that it would properly help that too.

For something so major, current || ( ) deps sound subpar either way.

So +1, haven't given it much thoughts but idea sounds good to me.

Unlike python, doubt I'll be testing all (old) LLVM targets USE on
bump and just wait for bug reports though :)
--
ionen

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmXBqH4ACgkQskQGsLCs QzRctAf/cQuMl9sRAYdRL3hMrf6JlRjWtrmgjyg86neN/jUBiDzhvwn/m+lHIu4n Kycvfzi4YDZFUsF6reqANBjWM3TdS1NxsDRwqJ7qKbW/mUrK9djV7XKzdjZmwujg 2lM+fgA5JrcXm9GBN5SulIGJn99QnkRIpZQlm3u94j1h0DQpvjr0HHaSGpiFdfMB +ErmFZIoma+oK4UGlrlDXk+0ckGFJOTsPZ1Sfa3O8wVKFfrvO354f3HV7ojv3HVH o2maXQGfzfXWQ34maTlsl9hRaOc+7I8Pfpj402B2Om1yeOwb656N1HfKiTIPoWsK os6q/+FvbXvNKbUAAT/ggp2cGCBqJw==
=iVHz
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)