| 1 |
On 03/08/2012 01:48 PM, Ciaran McCreesh wrote: |
| 2 |
> |
| 3 |
>> If they're code, they're code, and we need to execute them somehow. |
| 4 |
> |
| 5 |
> The notion of "execute them somehow" that's used doesn't fit in with |
| 6 |
> the #! interpreter model. You aren't executing ebuilds via an |
| 7 |
> interpreter. You're performing an action that involves using the data |
| 8 |
> and code in an ebuild multiple times and in multiple different ways, |
| 9 |
> and that may also involve doing the same to an installed package that |
| 10 |
> is being replaced. |
| 11 |
> |
| 12 |
|
| 13 |
I do understand that; but the fact that the data are computed in an ugly |
| 14 |
turing-complete language complicates things. |
| 15 |
|
| 16 |
Did someone already propose replacing EAPI=foo with a function call akin |
| 17 |
to inherit? |
| 18 |
|
| 19 |
eapi 4 |
| 20 |
inherit whatever |
| 21 |
... |
| 22 |
|
| 23 |
the call to eapi() would then set $EAPI accordingly. If the ebuild is |
| 24 |
being executed directly, it could exit $EAPI; otherwise, it would |
| 25 |
continue normally. That would give us an interface to the variable, and |
| 26 |
we wouldn't need to know the EAPI ahead of time to do it as long as it's |
| 27 |
the first function called in the ebuild. |
| 28 |
|
| 29 |
This is of course isomorphic to requiring a specific EAPI=4 format, but |
| 30 |
does allow you to do stupid things like x=`seq 4 4`; eapi $x; if you want. |
Archives