Thomas de Grenier de Latour wrote:
> On 2007/12/18, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 17 Dec 2007 17:10:46 -0700
>> Joe Peterson <[EMAIL PROTECTED]> 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.
--
[EMAIL PROTECTED] mailing list
