Gentoo Archives: gentoo-dev

From: Steve Long <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses
Date: Tue, 07 Oct 2008 16:00:37
Message-Id: gcg126$95h$1@ger.gmane.org
In Reply to: Re: [gentoo-dev] EAPI-2 and src_configure in eclasses by Alexis Ballier
1 Alexis Ballier wrote:
2
3 > Indeed; different names could be given to different implementations of
4 > the same thing, but that might completely kill the point of abstracting
5 > it.
6 > Maybe eclasses should die on unknown eapi; the fact is I really hate the
7 > current way it's done when switching an ebuild to EAPI-2 which uses
8 > an eclass that exports src_compile; most eclasses don't special case
9 > eapi-2 yet and we end up running econf twice at best. I fear that'll be
10 > the same with eapi-3, eapi-4, etc. (supposing that they'll support
11 > src_configure too)
12 >
13 >> > An EXPORT_FUNCTIONS ignoring any function its doesn't know for its
14 >> > eapi would help too.
15 >>
16 > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
17 >> An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place
18 >> checking for eclass screwups...
19 >
20 > yes; that's just a matter of choice though, but for eclasses it's
21 > probably not luxury.
22 >
23 Well it's simple enough to check (and give a QA warning) for unknown
24 functions; adding a check for a specific string prefix (or to exclude a
25 certain subset) in EXPORT_FUNCTIONS (based on current EAPI) is simple
26 enough too. Is that what you mean?
27
28 The behaviour to trigger could change eg for debug mode, or a repoman check.
29
30 I don't quite see how that deals with an eclass calling econf in its
31 exported src_compile? Seems like EAPI versioning for eclasses (with
32 implicit 0 only) is more what you're after for that issue (so the PM could
33 suppress src_configure if src_compile is going to resolve to an EAPI-0
34 eclass function, although the inheritance stack might prove problematic.)
35
36 Having to die for an unsupported EAPI seems like the wrong approach; if it's
37 not going to work the PM shouldn't source it. If it can be made to work by
38 filtering certain functions, that's doable.
39
40 In the worst case, an ebuild switching to EAPI will require eclass
41 maintenance; this is where the separation of elibs (useful code) and
42 eclasses (template ebuilds) would be useful, although that needs versioning
43 too.

Replies

Subject Author
Re: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses Alexis Ballier <aballier@g.o>