Ciaran McCreesh <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 10 Jun 2008 15:00:18 +0100:
> On Tue, 10 Jun 2008 09:49:04 -0400 > Richard Freeman <[EMAIL PROTECTED]> wrote: >> 4) Putting EAPI inside the ebuild, but in a manner that does not >> require sourcing using bash (ie comment at top of file). > - it doubles the number of file reads necessary during resolution. No comment, except that it should be cached after the first one, so the second read should be a memory read. > - it heavily restricts future syntax and meaning of EAPIs I don't see this. Putting it at a defined place in the ebuild and parsing it pre-source nails down the problem such that if a future format change is further incompatible, a primary EAPI can be defined that defines a further extension, a second line to look at in the ebuild, some external file, the filename, whatever, for the additional sub-eapi or whatever detail, much as extensions to various Internet RFCs have done when they've wanted to extend beyond what would fit in the then-current definitions. It does little to restrict the ultimate combined primary/secondary EAPI, where the primary simply defines where and how to look for the secondary. > - it makes comments have meaning Only if we choose the comment format, and then no more than shebang and similar solutions do. In the latter case it's an already recognized *ix solution. In the former, it's entirely possible to use a backward compatible EAPI= simple assignment that can be pre-parsed, and use the sub-eapi (minor part, in terms discussed elsewhere) if necessary to further define it using functions or the like. That said, I don't see the big deal to putting it in the file extension, when we're already breaking traditional content-defines-type rules by decreeing .ebuild extensions in the first place. I'd personally like to keep it a one-time fixed extension change, if only to force some discipline on the proliferation by forcing each new change to be reauthorized, meaning it's /really/ needed or it's simply not worth the trouble, but really, the precedent was already set when we accepted metadata in filename with the .ebuild thing in the first place, so there's little reason to fight it now, unless the proposal also eliminates that, and backward compatibility with it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
