On Friday, May 25, 2012 11:33:43 PM Ciaran McCreesh wrote:
> On Fri, 25 May 2012 15:02:32 -0500
> Dan Douglas <firstname.lastname@example.org> wrote:
> > If it were made a policy now that ebuilds and eclasses cannot depend
> > upon the subshell (for example, to set temporary positional
> > parameters or isolate temporary variables), then maybe someday in the
> > distant future this could be made the default, and in the meantime,
> > an option for those with new enough shells. Since dependence on the
> > subshell isn't very common, I think this should be feasible, and of
> > course as a workaround all that's required is to wrap any such
> > commands in parentheses.
> We'll be able to turn that on in a controlled way in EAPI 6.
Ah didn't know that. That's a solution for ebuilds anyway. How about for eclasses and user bashrc files? Does whatever EAPI setting is in effect for a particular ebuild apply to them? It isn't really worth toggling it on and off for individual files or functions in order to not break certain eclasses that conflict.
> said that, if we're reaching the point where speed of bash code is
> at all relevant, then ebuilds are doing something wrong...
That point was reached when someone decided a custom Bash parser just for ebuilds was necessary.