[gentoo-dev] [RFC] Introducing LLVM_TARGET

[gentoo-dev] [RFC] Introducing LLVM_TARGET

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: [gentoo-dev] [RFC] Introducing LLVM_TARGET

[Sam James]

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!

Re: [gentoo-dev] [RFC] Introducing LLVM_TARGET

[Sam James]

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!

Re: [gentoo-dev] [RFC] Introducing LLVM_TARGET

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]