Kent Fredric wrote: > 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? > I don't agree that it's a separate language: a lot of work goes into keeping BASH backward-compatible, so it's only when you use a new feature that your script will no longer work on an older version. We dealt with the move from bash2 to bash 3 quite well, I thought, and I don't see what's wrong with stipulating support for a new BASH version in a new EAPI: that seems quintessential use of the EAPI mechanism to me.
Another example would be use of extglob: as a scripting feature it needs to be enabled before any of the functions or script using it are even parsed, or BASH will bail with a syntax error. Specifying that it is so enabled in an EAPI (which I believe was done a while back) allows the ebuild author to use syntax that would otherwise fall over. Again, the EAPI mechanism works fine, and there is no need for a different extension, even though the syntax accepted has changed. So we already have an example of where syntax changes, not just the available environment, work with an EAPI inside the file, as it should be. > 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? > As Brian said, you still need an EAPI mechanism, and further you've still leaked metadata that simply doesn't need to be leaked. The only thing that has ever held up adoption of EAPI extraction using a simple EAPI="foo" declaration, matching tree-usage, is the fact that PMS does not specify which characters are allowed in an EAPI name. This was asked for a couple of years ago, iirc, and it is clearly necessary whether you scan for a token in the ebuild, or you stick EAPI into the filename. (After all you are even more restricted when you're talking about the filename, as opposed to a text string given in a script.) It just seems like a major hole in the spec, given that EAPI is so critical to how you deal with the ebuild, and characters allowed for other tokens such as category, package, version, keywords, USE-flags etc are specified. It would be necessary for GLEP-55, but is not mentioned therein, which I guess means the GLEP is under-specified as well. .eapi-NN just strikes me as similar to having M$ Word format as .doc95 .doc2000 and the like- a complete mess. Or indeed sticking the charset encoding (which has profound consequences when reading a file) from an HTML file into its filename. Again, a similar, if not worse, piece of metadata-- just extracting it is hard if you don't know the charset in advance, but I've never heard of anyone arguing that it should belong anywhere other than in the file, from where tools dealing with it locally can extract it and, say, emit the correct HTTP header. What I was referring to with an extension-per-language would be something like .pbuild for python-based build scripts, or .xbuild for your XML- declarative example, and so on. In each case, you'd still need a supporting infrastructure, but it's clear that you are using a completely different setup, and it's no longer a traditional BASH-based ebuild. It would be quite reasonable to suppose that you'd have EAPI specified there as well, since you'd want to be able to add to and change the features you support over time. Would you really want to change the extension each time you did, though? Regards, Steve. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
