From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KnEzE-0000i6-Ta for garchives@archives.gentoo.org; Tue, 07 Oct 2008 16:00:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 71CA8E0392; Tue, 7 Oct 2008 16:00:36 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1ECA6E0392 for ; Tue, 7 Oct 2008 16:00:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id EAD5A64EEC for ; Tue, 7 Oct 2008 16:00:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 required=5.5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gNuNfC35N2Z for ; Tue, 7 Oct 2008 16:00:28 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 396B9649CF for ; Tue, 7 Oct 2008 16:00:27 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KnEyw-00043J-6I for gentoo-dev@gentoo.org; Tue, 07 Oct 2008 16:00:18 +0000 Received: from 91.85.163.77 ([91.85.163.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Oct 2008 16:00:18 +0000 Received: from slong by 91.85.163.77 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Oct 2008 16:00:18 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: EAPI-2 and src_configure in eclasses Date: Tue, 07 Oct 2008 16:49:30 +0100 Message-ID: References: <18664.49886.385742.36918@a1ihome1.kph.uni-mainz.de> <20081005150727.15d307c6@googlemail.com> <20081005161546.31446f38@gentoo.org> <20081005152420.1d1e3256@googlemail.com> <20081005170740.4a067aef@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.85.163.77 User-Agent: KNode/0.10.9 Sender: news X-Archives-Salt: 076c2dd2-8e0e-4cf8-ac17-261b9f0f22e6 X-Archives-Hash: 7ff25eae8d0504af659bf9124753368b Alexis Ballier wrote: > Indeed; different names could be given to different implementations of > the same thing, but that might completely kill the point of abstracting > it. > Maybe eclasses should die on unknown eapi; the fact is I really hate the > current way it's done when switching an ebuild to EAPI-2 which uses > an eclass that exports src_compile; most eclasses don't special case > eapi-2 yet and we end up running econf twice at best. I fear that'll be > the same with eapi-3, eapi-4, etc. (supposing that they'll support > src_configure too) > >> > An EXPORT_FUNCTIONS ignoring any function its doesn't know for its >> > eapi would help too. >> > Ciaran McCreesh wrote: >> An EXPORT_FUNCTIONS ignoring incorrect usage makes one less place >> checking for eclass screwups... > > yes; that's just a matter of choice though, but for eclasses it's > probably not luxury. > Well it's simple enough to check (and give a QA warning) for unknown functions; adding a check for a specific string prefix (or to exclude a certain subset) in EXPORT_FUNCTIONS (based on current EAPI) is simple enough too. Is that what you mean? The behaviour to trigger could change eg for debug mode, or a repoman check. 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.) 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. 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.