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
