Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Date: Wed, 08 Oct 2008 03:21:37
Message-Id: 20081008032128.GA3448@hrair.corp.631h.metaweb.com
In Reply to: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses by Steve Long
1 On Tue, Oct 07, 2008 at 05:07:21PM +0100, Steve Long wrote:
2 > Ciaran McCreesh wrote:
3 >
4 > > On Sun, 5 Oct 2008 17:38:11 +0200
5 > > Ulrich Mueller <ulm@g.o> wrote:
6 > >> > By the way, do we really want to special case eapi-2 in every
7 > >> > eclass ? That's lot of code duplication and will get even worse
8 > >> > when we'll reach eapi-42. That would have been cool to have a pm
9 > >> > function that tells "has my eapi foo support" but that sort of
10 > >> > bites its tail that way.
11 > >>
12 > >> Hm, what about:
13 > >> [ "$(type -t src_configure)" == function ] && EXPORT_FUNCTIONS
14 > >> src_configure
15 > >>
16 > >> Or is this too fragile or trying to be too clever?
17 > >
18 > > It's illegal, according to PMS. It also won't work with Paludis, since
19 > > phase function definitions aren't made available until just before that
20 > > phase executes (there is a reason for this -- it provides us with a way
21 > > of identifying whether a package has a particular phase or not).
22 > >
23 > That seems a bit implementation-specific; how one alternative package
24 > manager generates that metadata isn't important (though it does seem odd
25 > that you think it has to be done at that point) nor should it get in the
26 > way.
27
28 Actually both alternative PM's do this now (>=pkgcore-0.4.7.9),
29 although in pkgcore's case the default phase functions are installed
30 after sourcing rather then at the time of invocation.
31
32 Long term, this is the correct way to go imo- the downside to it is
33 that a common sourcing env needs be defined at some point (newdepend,
34 newrdepend, etc) to avoid any question of what's available.
35
36 ~brian