[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

[Steve Long]

Thomas de Grenier de Latour wrote:

> On 2007/12/18, Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk> wrote:
>
>> On Mon, 17 Dec 2007 17:10:46 -0700
>> Joe Peterson <lavajoe@g.o> wrote:
>> > I probably missed some of the stuff leading up to this GLEP, but
>> > what is the problem with having the EAPI in the file and
>> > determining it by looking at the file contents?
>>
>> Motivation, second bullet point:
>>
>> | Possibility to extend the behaviour of inherit and add new global
>> | scope functions (as a result of not sourcing ebuilds with
>> | unsupported EAPI).
>
> Why can't it be in the file but readable without sourcing? For instance,
> it could be mandatory that EAPI=X, if present, must be the first
> non-blank and non-comment line of the ebuild (and it would then be
> checked after sourcing, if the ebuild is sourced, to bug on cases where
> it's redefined or unset afterwards).
>
There's _no_ need to source, nor constrain like that, for a simple one-line
variable, eg: 
$ sed -nr '/^[[:space:]]*DESCRIPTION="([^"]*)".*/ { s//\1/p;q; }' \
     app-portage/autounmask/autounmask-0.21.ebuild
autounmask - Unmasking packages the easy way

eapi=$(sed -nr '/^[[:space:]]*EAPI="([^"]*)".*/ { s//\1/p;q; }' foo.ebuild)
[[ $eapi ]] && checkAPI "$eapi"
..would do it in bash (empty if unset in ebuild) assuming the conventional
EAPI="xx" format is used. Other languages can call system() easily enough.


-- 
gentoo-dev@g.o mailing list