| 1 |
On Mon, 23 Feb 2009 15:53:20 +0000 |
| 2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
|
| 4 |
> On Mon, 23 Feb 2009 08:43:09 -0700 |
| 5 |
> Steve Dibb <beandog@g.o> wrote: |
| 6 |
> > Plus, I don't really grasp the whole "we have to source the whole |
| 7 |
> > ebuild to know the EAPI version" argument. It's one variable, in |
| 8 |
> > one line. Can't a simple parser get that and go from there? |
| 9 |
> |
| 10 |
> Not true. This is entirely legal: |
| 11 |
> |
| 12 |
> In pkg-1.ebuild: |
| 13 |
> |
| 14 |
> EAPI="${PV}" |
| 15 |
> printf -v EAPI '%s' 4 |
| 16 |
> inherit foo |
| 17 |
> EAPI="2" |
| 18 |
|
| 19 |
Which begs the question: is it really worth allowing it? |
| 20 |
If we only allow constant assignments (which is an implicit restriction |
| 21 |
in the file extension version) then this can be parsed easily with |
| 22 |
grep/tr/awk/etc and can be the magic eapi guessing. Of course the tree |
| 23 |
has to be checked before implementing this and we'll have to wait a |
| 24 |
good amount of time before breaking the current eapi bash-parsing but |
| 25 |
I'm not aware of any eapi proposal that would break the current behavior |
| 26 |
and would be usable in the main tree within a reasonable amount of |
| 27 |
time such that we can't ignore backward compatibility. |
| 28 |
|
| 29 |
|
| 30 |
> In foo.eclass: |
| 31 |
> |
| 32 |
> EAPI="3" |
| 33 |
|
| 34 |
I thought this was prohibited. |
| 35 |
|
| 36 |
Alexis. |
Archives