On Sun, 5 Oct 2008 15:24:20 +0100
Ciaran McCreesh <ciaran.mccreesh@...> wrote:

> On Sun, 5 Oct 2008 16:15:46 +0200
> Alexis Ballier <aballier@g.o> wrote:
> > An eapi.eclass with such functions and lists of eapi & features
> > maintained there could help though.
> 
> The problem is, 'features' change between EAPIs. For example, all
> three EAPIs have src_compile, but it does different things for all
> three. One can't assume that a feature working for current EAPIs will
> carry on working for future EAPIs, and even if it does there can be
> other interactions that break.

Indeed; different names could be given to different implementations of
the same thing, but that might completely kill the point of abstracting
it.
Maybe eclasses should die on unknown eapi; the fact is I really hate the
current way it's done when switching an ebuild to EAPI-2 which uses
an eclass that exports src_compile; most eclasses don't special case
eapi-2 yet and we end up running econf twice at best. I fear that'll be
the same with eapi-3, eapi-4, etc. (supposing that they'll support
src_configure too)

> > An EXPORT_FUNCTIONS ignoring any function its doesn't know for its
> > eapi would help too.
> 
> An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place
> checking for eclass screwups...

yes; that's just a matter of choice though, but for eclasses it's
probably not luxury.


Alexis.