Re: Fwd: curious...

[Ralf Wildenhues]

* Kyle Sallee wrote on Sat, Oct 21, 2006 at 07:52:17PM CEST:
> Okay, the 26M trace was probably typical of almost any
> of the libtool invocations during the long parts of compiling koffice.

Thanks for the trace.  First, could you grab a new CVS HEAD snapshot of
Libtool (from the web page), build and install that somewhere, and redo
the link with it?  CVS HEAD has some more optimizations.

You need to either rerun all the autotools on the package (in that case
it helps to have all of Autoconf, Automake, and Libtool installed below
the same $prefix), or, for a quick hack, you can try to just override
$LIBTOOL, like so:
  make LIBTOOL=/my/new/CVS-HEAD/libtool

> Just look at function func_ ...oh the one that can strip off the leading
> -R from a variable... sorry I forgot to add the name of that one to the 
> notes.
> Everytime it executes it forks sed.

Not in CVS HEAD, unless you have a very losing shell.  I already wrote
that.  The func_stripname in HEAD is quite fast for all modern shells.

> However, the proposed change goes against the tradition.
> The tradition is to use bash code, no matter how slow,
> if it it can be written in a way to accomplish the task
> with the possibility of not forking to external utilities.

Just repeating this nonsense does not make it true.
It merely makes it sound like you did not read my replies.

> Obviously the libtool shell script has a certain
> feel to it, a certain style, a certain obviousness
> about how the authors believe tasks should be accomplished.

No.  I for one am very pragmatic about it.  To me, style is secondary to
portability, robustness, efficiency, and readability.

> I am proposing an almost a 100% opposite solution.
> Therefore, I can not simply submit such a contribution and
> expect it to be accepted without sufficient debate and explanation
> of why 3 definite forks is better than an unknown possibility ranging
> between 0 and an infinite amount.

You have understood wrongly.  What you need in support of changes is
timings to prove that your change actually helps.

> The changes to libtool script are so trivial that I need not do them.

This is where you are fundamentally wrong.  If you don't write them,
then I for one will only go about it once I have enough time and see
the need (as in: I see timing evidence for actual, real cases).  And
also you are wrong that all such changes are trivial, given portability
constraints.

> I do no propose destablizing libtool before the 2.0 release.

Oh, there is no problem if you have good patches but we deem them too
destabilizing for 2.0: we can simply postpone them and apply them
afterwards.

Cheers,
Ralf