On Wed, 19 Dec 2007 20:28:55 -0500
Richard Freeman <rich@...> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 19 Dec 2007 18:59:47 -0500
> > Richard Freeman <rich@...> wrote:
> >> Am I missing something?
> >
> > Yes. You're missing all the explanations that have already been
> > given about why it's impossible to parse ebuilds using anything
> > other than bash.
>
> If the EAPI can be parsed from a filename without using bash, why
> couldn't it be parsed from a line in the ebuild contents without using
> bash?
Because a) a future EAPI might want to change EAPI into a function
rather than a variable, b) there are a zillion ways of setting a
variable in bash and people already use all of them and c) introducing
new weird format requirements is silly.
> An inelegant solution (but possibly more elegant than using filenames)
> might be to put the EAPI on the first line of the ebuild, with nothing
> else on that line. Then a simple head -n 1 <file> retrieves the EAPI.
> Certainly not pretty - but perhaps nicer than putting the EAPI in the
> filename itself. And I don't see how it is any less flexible than
> putting it in the filename
It imposes format restrictions upon the ebuild. Currently there aren't
any such format restrictions. EAPIs are designed to *remove* this kind
of inflexibility, not add to it.
> if nothing else it would allow you a
> larger character set without making command-line work painful.
A large character set for EAPI is silly. Anyone naming an EAPI that
isn't a-zA-Z0-9-+_ should be taken out and shot.
> However, I still don't see how a regexp wouldn't work - if you made
> the policy that all ebuilds must have a line that says:
> EAPI="<something>" - exactly. No spaces, quotes mandatory, etc. That
> can't be any less painful on devs than putting the EAPI in the
> filename, and it could be checked for by repoman/etc. Or, if package
> managers are willing to do a little more work we could allow a little
> whitespace and make things easier on devs.
And then EAPI 3 comes along and says "Set EAPI using the eapi
function". Oops, we're back to the original issue all over again.
--
Ciaran McCreesh
|