| 1 |
On Thu, 08 Mar 2012 16:35:14 -0500 |
| 2 |
Michael Orlitzky <michael@××××××××.com> wrote: |
| 3 |
|
| 4 |
> On 03/08/2012 01:48 PM, Ciaran McCreesh wrote: |
| 5 |
> > |
| 6 |
> >> If they're code, they're code, and we need to execute them somehow. |
| 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 |
| 11 |
> > data and code in an ebuild multiple times and in multiple different |
| 12 |
> > ways, and that may also involve doing the same to an installed |
| 13 |
> > package that is being replaced. |
| 14 |
> > |
| 15 |
> |
| 16 |
> I do understand that; but the fact that the data are computed in an |
| 17 |
> ugly turing-complete language complicates things. |
| 18 |
> |
| 19 |
> Did someone already propose replacing EAPI=foo with a function call |
| 20 |
> akin to inherit? |
| 21 |
> |
| 22 |
> eapi 4 |
| 23 |
> inherit whatever |
| 24 |
> ... |
| 25 |
> |
| 26 |
> the call to eapi() would then set $EAPI accordingly. If the ebuild is |
| 27 |
> being executed directly, it could exit $EAPI; otherwise, it would |
| 28 |
> continue normally. That would give us an interface to the variable, |
| 29 |
> and we wouldn't need to know the EAPI ahead of time to do it as long |
| 30 |
> as it's the first function called in the ebuild. |
| 31 |
> |
| 32 |
> This is of course isomorphic to requiring a specific EAPI=4 format, |
| 33 |
> but does allow you to do stupid things like x=`seq 4 4`; eapi $x; if |
| 34 |
> you want. |
| 35 |
|
| 36 |
What advantage does it give us? We still can't change ebuild syntax in |
| 37 |
global scope because bash will barf. |
| 38 |
|
| 39 |
-- |
| 40 |
Best regards, |
| 41 |
Michał Górny |
Archives