1 |
On Tue, 11 Dec 2007 16:59:28 -0500 |
2 |
Doug Klima <cardoe@g.o> wrote: |
3 |
|
4 |
> Since it doesn't appear the question was answered by the last thread. |
5 |
> I'm starting a new thread. |
6 |
|
7 |
The only sane solution I can think of is that eclasses shouldn't be |
8 |
allowed to change EAPI, but use conditionals to behave differently if |
9 |
needed. Mixing two (or more) different arbitrary EAPIs isn't going to |
10 |
work as after the inital parsing package managers will only see the |
11 |
last EAPI value anyway. Also there is no guarantee that future EAPI |
12 |
versions will be backwards compatible, so if eclasses could have an |
13 |
EAPI version it would eventually require that all packages using it |
14 |
need the same EAPI version (similar for nested inheritance). |
15 |
|
16 |
It's trivial to let inherit check that an eclass doesn't modify EAPI, |
17 |
and adding the conditional code to eclasses isn't difficult either: |
18 |
|
19 |
foo.eclass: |
20 |
|
21 |
if [ -z "$EAPI" ]; then |
22 |
inherit foo-eapi0 |
23 |
fi |
24 |
case "$EAPI" in |
25 |
0) |
26 |
inherit foo-eapi0 |
27 |
;; |
28 |
1|2) |
29 |
inherit foo-eapi1_2 |
30 |
;; |
31 |
*) |
32 |
eerror "foo.eclass: unsupported EAPI value $EAPI" |
33 |
;; |
34 |
esac |
35 |
|
36 |
# EAPI independent code here |
37 |
|
38 |
Obviously instead of specific eclasses one could also inline the |
39 |
relevant code. The only two issues I see in this concept are the |
40 |
eventual multiplication of eclasses and the lack of proper error |
41 |
handling for unsupported EAPIs. |
42 |
|
43 |
Marius |
44 |
|
45 |
PS: Yes, this idea has been mentioned in the old thread as well |
46 |
|
47 |
-- |
48 |
Public Key at http://www.genone.de/info/gpg-key.pub |
49 |
|
50 |
In the beginning, there was nothing. And God said, 'Let there be |
51 |
Light.' And there was still nothing, but you could see a bit better. |