Hi Gary, * 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? Thanks, Ralf
