On 03/09/12 10:05, Zac Medico wrote:
>> Surely we can source one or two lines of the ebuild safely, like the
>> example shows?
> Why would we though, when sourcing is a relatively costly operation, and
> there are much more efficient ways to get the EAPI?
There do not seem to be any that people agree on =)
I mean, it's /easy/ to get the EAPI. There's a list of ways on the GLEP,
but all of them have trade-offs.
The header comment seems to be the preference in this thread. The
advantage that the eapi function has over a comment is that it's not
magic -- it's just normal bash syntax. So we've addressed that issue at
a small performance cost (we're really only sourcing the ebuild up to
Whether or not that trade-off is worth it, who knows. I would prefer to
make it work before we make it fast; but new ideas can't hurt
considering nobody has agreed on an old one.
> Also, you've got a chicken and egg problem, since you're assuming that
> your eapi() function is going to be available in the global environment
> when the ebuild is sourced. The whole point of knowing the EAPI in
> advance is so that we will be able to make changes to the global
> environment, such as add, remove, or change the behavior of _any_ function.
Nah, at the top of the ebuild, you would have,
until package managers catch up, just like we would have to do with the
comment. Once they've caught up, we can drop the EAPI= assignment, and
begin using new features after the call to 'eapi'.