1 |
On Sun, 5 Oct 2008 15:24:20 +0100 |
2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
3 |
|
4 |
> On Sun, 5 Oct 2008 16:15:46 +0200 |
5 |
> Alexis Ballier <aballier@g.o> wrote: |
6 |
> > An eapi.eclass with such functions and lists of eapi & features |
7 |
> > maintained there could help though. |
8 |
> |
9 |
> The problem is, 'features' change between EAPIs. For example, all |
10 |
> three EAPIs have src_compile, but it does different things for all |
11 |
> three. One can't assume that a feature working for current EAPIs will |
12 |
> carry on working for future EAPIs, and even if it does there can be |
13 |
> other interactions that break. |
14 |
|
15 |
Indeed; different names could be given to different implementations of |
16 |
the same thing, but that might completely kill the point of abstracting |
17 |
it. |
18 |
Maybe eclasses should die on unknown eapi; the fact is I really hate the |
19 |
current way it's done when switching an ebuild to EAPI-2 which uses |
20 |
an eclass that exports src_compile; most eclasses don't special case |
21 |
eapi-2 yet and we end up running econf twice at best. I fear that'll be |
22 |
the same with eapi-3, eapi-4, etc. (supposing that they'll support |
23 |
src_configure too) |
24 |
|
25 |
> > An EXPORT_FUNCTIONS ignoring any function its doesn't know for its |
26 |
> > eapi would help too. |
27 |
> |
28 |
> An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place |
29 |
> checking for eclass screwups... |
30 |
|
31 |
yes; that's just a matter of choice though, but for eclasses it's |
32 |
probably not luxury. |
33 |
|
34 |
|
35 |
Alexis. |