1 |
On Friday, May 25, 2012 11:33:43 PM Ciaran McCreesh wrote: |
2 |
> On Fri, 25 May 2012 15:02:32 -0500 |
3 |
> Dan Douglas <ormaaj@×××××.com> wrote: |
4 |
> > If it were made a policy now that ebuilds and eclasses cannot depend |
5 |
> > upon the subshell (for example, to set temporary positional |
6 |
> > parameters or isolate temporary variables), then maybe someday in the |
7 |
> > distant future this could be made the default, and in the meantime, |
8 |
> > an option for those with new enough shells. Since dependence on the |
9 |
> > subshell isn't very common, I think this should be feasible, and of |
10 |
> > course as a workaround all that's required is to wrap any such |
11 |
> > commands in parentheses. |
12 |
> |
13 |
> We'll be able to turn that on in a controlled way in EAPI 6. |
14 |
|
15 |
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. |
16 |
|
17 |
> Having |
18 |
> said that, if we're reaching the point where speed of bash code is |
19 |
> at all relevant, then ebuilds are doing something wrong... |
20 |
> |
21 |
|
22 |
That point was reached when someone decided a custom Bash parser just for ebuilds was necessary. :) |
23 |
|
24 |
-- |
25 |
Dan Douglas |