On Thu, 08 Mar 2012 16:35:14 -0500
Michael Orlitzky <michael@...> wrote:

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

What advantage does it give us? We still can't change ebuild syntax in
global scope because bash will barf.

-- 
Best regards,
Michał Górny