>>>>> 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

Reply via email to