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