On Sun, 5 Oct 2008 15:24:20 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Sun, 5 Oct 2008 16:15:46 +0200 > Alexis Ballier <[EMAIL PROTECTED]> 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.
signature.asc
Description: PGP signature
