On 19 March 2012 14:12, Steven J Long <sl...@rathaus.eclipse.co.uk> wrote:
>
> As for non-bash ebuilds, I have always agreed with antarus that they should
> simply use a different extension. Adding a new extension per source language
> is a *lot* cleaner than one per EAPI.

Ok: If we take this notion and enshrine it in stone:

If we assume Bash 4 is a seperate language from Bash 3, as its
syntax-backwards-incompatible, is it fair to suggest that for some
future EAPI which require Bash 4, that the extension change to suit?

ie:  move from .ebuild  to .ebuild4 , where '.ebuild' conveys the
format is bash, and that '.ebuild4' is bash4 only?

That way you have a forwards declaration of the syntax/file format
required to parse the file, but no declaration of the EAPI, so you're
not breaking encapsulation.

This is breaking the direct file==eapi connection, but still
maintaining a loose file<->eapi connection.

Its /sort/ of like the "one time extension change" proposal, except
its less 'arbitrary' than something like .eb , and it gives us the
future option of changing the suffix again if bash 5 comes out with
different syntax.

Then we can do

.ebuild = EAPI 0 - 4    & bash >= 3
.ebuild4 = EAPI5 - 9    & bash >= 4
.ebuild5 = EAPI10 - 15 & bash >= 5

Thoughts?

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Reply via email to