| 1 |
On Wed, Sep 14, 2011 at 01:18, Ciaran McCreesh wrote: |
| 2 |
> On Tue, 13 Sep 2011 10:29:48 -0400 Mike Frysinger wrote: |
| 3 |
>> > You don't do it by checking IUSE. You do it by having the ebuild |
| 4 |
>> > define a variable like WANT_MONKEY_SUPPORT. |
| 5 |
>> |
| 6 |
>> it's a crap shoot. as long as Michał's proposed func doesnt attempt |
| 7 |
>> to make guarantees that don't exist now, i think it's fine. we have |
| 8 |
>> ebuilds/eclasses that are already using it, so unifying it purely for |
| 9 |
>> the [+-] cleanup makes sense to me. |
| 10 |
> |
| 11 |
> Providing a function, especially in eutils, makes people think that it |
| 12 |
> will work. It won't work, so the solution is to fix ebuilds and |
| 13 |
> eclasses that are doing it and make sure people realise why they can't |
| 14 |
> do that. |
| 15 |
|
| 16 |
it depends on the context. in global scope, eclasses cant leverage |
| 17 |
IUSE from the ebuild. this is semi-obvious, and you provided some |
| 18 |
illustrative examples. |
| 19 |
|
| 20 |
however, why wont this work sanely in src_* or pkg_* funcs ? the env |
| 21 |
there is the one constructed by the PM which includes the merged IUSE |
| 22 |
values. |
| 23 |
|
| 24 |
and it should work sanely for eclasses/ebuilds checking their own |
| 25 |
IUSE. toolchain.eclass for example does just this ... based on the |
| 26 |
version of gcc the eclass is being used, it selectively adds flags to |
| 27 |
IUSE. then the rest of the eclass tests that for available |
| 28 |
functionality rather than copying & pasting version limits all over. |
| 29 |
granted toolchain.eclass isnt the norm, but if it's going to work |
| 30 |
there, it has to work in general. |
| 31 |
-mike |
Archives