Gentoo Archives: gentoo-dev

From: Alexis Ballier <aballier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] EAPI-2 and src_configure in eclasses
Date: Sun, 05 Oct 2008 15:07:44
Message-Id: 20081005170740.4a067aef@gentoo.org
In Reply to: Re: [gentoo-dev] EAPI-2 and src_configure in eclasses by Ciaran McCreesh
1 On Sun, 5 Oct 2008 15:24:20 +0100
2 Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
3
4 > On Sun, 5 Oct 2008 16:15:46 +0200
5 > Alexis Ballier <aballier@g.o> wrote:
6 > > An eapi.eclass with such functions and lists of eapi & features
7 > > maintained there could help though.
8 >
9 > The problem is, 'features' change between EAPIs. For example, all
10 > three EAPIs have src_compile, but it does different things for all
11 > three. One can't assume that a feature working for current EAPIs will
12 > carry on working for future EAPIs, and even if it does there can be
13 > other interactions that break.
14
15 Indeed; different names could be given to different implementations of
16 the same thing, but that might completely kill the point of abstracting
17 it.
18 Maybe eclasses should die on unknown eapi; the fact is I really hate the
19 current way it's done when switching an ebuild to EAPI-2 which uses
20 an eclass that exports src_compile; most eclasses don't special case
21 eapi-2 yet and we end up running econf twice at best. I fear that'll be
22 the same with eapi-3, eapi-4, etc. (supposing that they'll support
23 src_configure too)
24
25 > > An EXPORT_FUNCTIONS ignoring any function its doesn't know for its
26 > > eapi would help too.
27 >
28 > An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place
29 > checking for eclass screwups...
30
31 yes; that's just a matter of choice though, but for eclasses it's
32 probably not luxury.
33
34
35 Alexis.

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] EAPI-2 and src_configure in eclasses Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
[gentoo-dev] Re: EAPI-2 and src_configure in eclasses Steve Long <slong@××××××××××××××××××.uk>