On 7 Aug 2010, at 18:15, Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf,
> * Ralf Wildenhues wrote on Mon, Jun 28, 2010 at 07:34:35AM CEST: >> * Gary V. Vaughan wrote on Mon, Jun 28, 2010 at 01:24:39AM CEST: >>> Looking through the XSI substitutions, or more correctly the bash/ksh >>> func_append usage, there's room here to consistently use func_append >>> everywhere to make for easier maintenance... but rather than take the >>> additional overhead of a function call in the sensitive quadratic scaling >>> parts that prompted the introduction of the += idiom in the first place: >>> use the libtool rewriting machinery to substitute inline `+=' where >>> possible, with a fallback to the earlier longhand otherwise. >>> >>> Okay to push? >> >> OK thanks! > > I approved this patch v2.2.10-40-g0da7d80 aka. > <http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00190.html> > back then without much concern, but trying to debug libtool script > issues, and seeing users struggle with nonportable shell constructs > (even if these turn out to be user side issues later): > <http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7475> > > I'm now wondering whether we shouldn't maybe reevaluate the inline > expansion of nonportable code. The change has an unknown performance > upside and a known usability downside of needing to hack several places > rather than just one func_append instance. Has the speedup been > measured? If not, is there a chance that we can somehow agree on either > having numbers to prove that this actually helps in practice, or > otherwise reverting the inlining part of this patch? Sure. Whatever you think is best is generally fine with me. I don't see that the +=/func_append substitution is causing any additional concerns to the XSI function substitution though. The whole function substitution is really a single issue in this case, right? Either we need to work on it to the point where it will DTRT reliably, or else we should remove all of the function substitution machinery, and go back to writing portable shell everywhere. I'd rather not do that actually, but I don't have time to work on getting timings or looking at bugs right now, so I'm more than happy to leave the decision in your capable hands. Cheers, -- Gary V. Vaughan (g...@gnu.org)
