On Tue, Oct 07, 2008 at 05:07:21PM +0100, Steve Long wrote: > Ciaran McCreesh wrote: > > > On Sun, 5 Oct 2008 17:38:11 +0200 > > Ulrich Mueller <[EMAIL PROTECTED]> wrote: > >> > By the way, do we really want to special case eapi-2 in every > >> > eclass ? That's lot of code duplication and will get even worse > >> > when we'll reach eapi-42. That would have been cool to have a pm > >> > function that tells "has my eapi foo support" but that sort of > >> > bites its tail that way. > >> > >> Hm, what about: > >> [ "$(type -t src_configure)" == function ] && EXPORT_FUNCTIONS > >> src_configure > >> > >> Or is this too fragile or trying to be too clever? > > > > It's illegal, according to PMS. It also won't work with Paludis, since > > phase function definitions aren't made available until just before that > > phase executes (there is a reason for this -- it provides us with a way > > of identifying whether a package has a particular phase or not). > > > That seems a bit implementation-specific; how one alternative package > manager generates that metadata isn't important (though it does seem odd > that you think it has to be done at that point) nor should it get in the > way.
Actually both alternative PM's do this now (>=pkgcore-0.4.7.9), although in pkgcore's case the default phase functions are installed after sourcing rather then at the time of invocation. Long term, this is the correct way to go imo- the downside to it is that a common sourcing env needs be defined at some point (newdepend, newrdepend, etc) to avoid any question of what's available. ~brian
pgplTnmKBbhpJ.pgp
Description: PGP signature