libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add func_append_quoted and do inline func_append substitutio


From: Ralf Wildenhues
Subject: Re: [PATCH] Add func_append_quoted and do inline func_append substitutions.
Date: Sat, 7 Aug 2010 13:15:52 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]