On Thu, 08 Mar 2012 16:35:14 -0500 Michael Orlitzky <mich...@orlitzky.com> 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
signature.asc
Description: PGP signature
