Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses

[Alexis Ballier]

> I don't quite see how that deals with an eclass calling econf in its
> exported src_compile? Seems like EAPI versioning for eclasses (with
> implicit 0 only) is more what you're after for that issue (so the PM
> could suppress src_configure if src_compile is going to resolve to an
> EAPI-0 eclass function, although the inheritance stack might prove
> problematic.)

I don't know of any way for the pm to detect if the eclass supports
given eapi or not, and even less if exported src_compile will be eapi-2
aware or not.

> Having to die for an unsupported EAPI seems like the wrong approach;
> if it's not going to work the PM shouldn't source it. If it can be
> made to work by filtering certain functions, that's doable.

I tend to see dying for an unsupported eapi as eclass versioning for
the poor people but that's the only thing we can do atm afaik. For now,
all eapi are backward compatible wrt to sourcing so that's not really
an issue to source an eapi-0 eclass withing an eapi-2 ebuild. I think
there has been a discussion on eclasses vs eapi before and the outcome
was that eclasses should add hacky checks for eapi; which means to me
we'll have to adjust those hacky checks for each new eapi.

However, for now, not dying allows workarounds like:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/ogmrip/ogmrip-0.12.2.ebuild?view=markup
but I don't consider it very pretty.

> In the worst case, an ebuild switching to EAPI will require eclass
> maintenance; this is where the separation of elibs (useful code) and
> eclasses (template ebuilds) would be useful, although that needs
> versioning too.

The problem will remain for this new definition of eclasses; glad to
see you're volunteering to fix every single eclass that exports a
src_compile/unpack function for eapi-2 :)

If by template ebuilds you mean the EXPORT_FUNCTIONS line and some deps,
then I dont see the difference between eapi versioning for eclasses and
a switch/case for each eapi in the unversioned eclass. Note that "useful
code" can differ upon eapi (I'm thinking about has_version checks).

Regards,

Alexis.