| 1 |
On 19 March 2012 14:12, Steven J Long <slong@××××××××××××××××××.uk> wrote: |
| 2 |
> |
| 3 |
> As for non-bash ebuilds, I have always agreed with antarus that they should |
| 4 |
> simply use a different extension. Adding a new extension per source language |
| 5 |
> is a *lot* cleaner than one per EAPI. |
| 6 |
|
| 7 |
Ok: If we take this notion and enshrine it in stone: |
| 8 |
|
| 9 |
If we assume Bash 4 is a seperate language from Bash 3, as its |
| 10 |
syntax-backwards-incompatible, is it fair to suggest that for some |
| 11 |
future EAPI which require Bash 4, that the extension change to suit? |
| 12 |
|
| 13 |
ie: move from .ebuild to .ebuild4 , where '.ebuild' conveys the |
| 14 |
format is bash, and that '.ebuild4' is bash4 only? |
| 15 |
|
| 16 |
That way you have a forwards declaration of the syntax/file format |
| 17 |
required to parse the file, but no declaration of the EAPI, so you're |
| 18 |
not breaking encapsulation. |
| 19 |
|
| 20 |
This is breaking the direct file==eapi connection, but still |
| 21 |
maintaining a loose file<->eapi connection. |
| 22 |
|
| 23 |
Its /sort/ of like the "one time extension change" proposal, except |
| 24 |
its less 'arbitrary' than something like .eb , and it gives us the |
| 25 |
future option of changing the suffix again if bash 5 comes out with |
| 26 |
different syntax. |
| 27 |
|
| 28 |
Then we can do |
| 29 |
|
| 30 |
.ebuild = EAPI 0 - 4 & bash >= 3 |
| 31 |
.ebuild4 = EAPI5 - 9 & bash >= 4 |
| 32 |
.ebuild5 = EAPI10 - 15 & bash >= 5 |
| 33 |
|
| 34 |
Thoughts? |
| 35 |
|
| 36 |
-- |
| 37 |
Kent |
| 38 |
|
| 39 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
| 40 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
Archives