From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MBnIn-00039D-CQ for garchives@archives.gentoo.org; Wed, 03 Jun 2009 10:02:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BC1A9E0568; Wed, 3 Jun 2009 10:02:31 +0000 (UTC) Received: from email.aon.at (warsl404pip5.highway.telekom.at [195.3.96.77]) by pigeon.gentoo.org (Postfix) with ESMTP id 494C9E0568 for ; Wed, 3 Jun 2009 10:02:31 +0000 (UTC) Received: (qmail 678 invoked from network); 3 Jun 2009 10:02:29 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on WARSBL503.highway.telekom.at X-Spam-Level: * Received: from 88-117-60-197.adsl.highway.telekom.at (HELO [10.0.0.1]) ([88.117.60.197]) (envelope-sender ) by smarthub95.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 3 Jun 2009 10:02:29 -0000 Subject: Re: [gentoo-dev] A new glep: Ebuild format and metadata handling From: Michael Haubenwallner To: gentoo-dev@lists.gentoo.org In-Reply-To: <200905311556.19190.patrick@gentoo.org> References: <200905311556.19190.patrick@gentoo.org> Content-Type: text/plain Date: Wed, 03 Jun 2009 12:02:28 +0200 Message-Id: <1244023348.1633.93.camel@salomon-22> 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 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 1671a399-3ebe-41b6-999e-abd118cc04a8 X-Archives-Hash: dcdaf1e9c2c2b6eacf076a38c03688c9 On Sun, 2009-05-31 at 15:56 +0200, Patrick Lauer wrote: Thank you for collecting this up! > parsers: The current practise of putting the eapi definition near the top of > the ebuild, combined with the need to state it for all non-EAPI0 ebuilds, > suggests that it can be parsed without having to source the ebuild. Would it improve parsers' performance to explicitly define EAPI="0" in EAPI0 ebuilds too, so it always can find an EAPI value? > "haubi" > He proposes to use an eapi.eclass and define eapi as a function. Erm, unlike earlier I did not propose eapi as a function this time. Instead, my proposal is identical to the "parsers" one, but with a backwards compatible syntax for defining the EAPI value that allows to have non-parsing PMs (nearly) silently ignore the ebuild, so we do not have to wait another extended period (=year) to put "parsed" EAPI values in the tree after a "parsing" PM became stable. This backwards compatibility syntax is done with the eapi.eclass, which does nothing but early exit when inherit'ed by an old (=non-parsing) PM. It is up to the "parsing" PM (the PMS) if 'eapi.eclass' actually gets read in, as the implementation of 'inherit' is part of the PM and has to detect "eapi" as special argument anyway, otherways it would fail to find "4.eclass" when used this way: > inherit eapi 4 But I can also think of this syntax: EAPI="4" # parsers read this line only inherit eapi # compat for non-parsing PM only Here the 'inherit eapi' line can be dropped as soon as we do not need to support non-parsing PMs any more. However, parsing PMs either need to ignore "eapi" as argument to 'inherit', or need to inform eapi.eclass somehow that the EAPI was parsed already. There might be a better name than 'eapi.eclass' here. With 'eapicompat.eclass' fex this would read: EAPI="4" inherit eapicompat Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level