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