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 |