>>>>> On Thu, 8 Mar 2012, Michał Górny wrote:
>> *** Proposal 1: "Parse the EAPI assignment statement" ***
>>
>> [...]
>>
>> Written in a more formal way, appropriate for a specification:
>> - Ebuilds must contain at most one EAPI assignment statement.
>> - It must occur within the first N lines of the ebuild (N=10 and N=30
>> have been suggested).
>> - The statement must match the following regular expression (extended
>> regexp syntax):
>> ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$
> I'd make the regexp less strict -- at least allow whitespace around '='.
> If the intent is to not rely on a specific bash version for a global
> scope, why should we limit it to the (current) bash syntax?
This could certainly be done ...
> And it may be also a good idea to not rely on a specific line format,
> so e.g. 'dnl EAPI=4' will work as well.
... but loosening it too much looks a little dangerous, because it
would probably match comments and could produce unintended matches.
If we allow for a general syntax, we should restrict it to the first
line of the ebuild. But that is proposal 2 then.
>> 1b) It is only applied for EAPI 5 and later (which means that the
>> result of the EAPI parsing would be discarded for earlier EAPIs).
> Err... so what happens if 'new parsing' detects EAPI 4 and 'old
> parsing' detects EAPI 5?
This cannot happen for a legal ebuild:
- If the ebuild is EAPI 4, then sourcing it ("old parsing") must
detect EAPI 4.
- If the ebuild is EAPI 5, then "new parsing" must detect EAPI 5.
> Or more exactly, how does it know when an older EAPI is used if it
> is supposed to not use the value it uses to detect EAPI?
If new parsing detects EAPI 5 or later, then use this value (and do a
sanity check after the ebuild has been sourced). Otherwise, discard
the value determined by new parsing and detect the EAPI in the
traditional way by sourcing the ebuild.
Ulrich
