Re: libtool 2.4 args parsing incredibly slow

[Charles Wilson]

On 1/27/2011 9:46 AM, Peter O'Gorman wrote:
> Hi Ralf, Charles, see below.
> 
> On 01/27/2011 12:56 AM, Ralf Wildenhues wrote:
>> This can be just
>>    case " $* " in
>>    *\ --lt*)
>>
> 
> Thanks, I will test a patch like this later today.
> 
>> I like this as a first measure.  

Yes, I've been following the discussion, and this looks fine to me.  I
have reservations about the others (forking sed to process the whole
line at once -- quoting problems, fork-vs-loop speed tradeoffs on other
platforms especially cygwin with its PAINFULLY slow fork, etc).

>> But can we also reconsider detecting
>> --lt-* flags only *early* in the command line?  Hmm, since we don't know
>> which native options accept arguments, that's always painful when
>> someone wants to be able to do TOOL='./tool --opt1 arg --opt2' and
>> somebody else appends TOOLFLAGS=--lt-foo, but maybe we can let at least
>> '--' delimit our search?
>
> Well, Charles originally added this and in the email I found (and I'm
> not currently caffinated enough to go looking for it again, sorry), he
> argued for having the --lt- arguments anywhere on the command line.

We originally had a clause where '--' delimited the search, but were
forced to remove it due to a bug report (bug report in msg00053):

http://lists.gnu.org/archive/html/libtool-patches/2008-05/msg00053.html
http://lists.gnu.org/archive/html/libtool-patches/2008-05/msg00063.html
http://lists.gnu.org/archive/html/libtool-patches/2008-05/msg00064.html
http://lists.gnu.org/archive/html/libtool-patches/2008-05/msg00066.html
http://lists.gnu.org/archive/html/libtool-patches/2008-05/msg00067.html

There were some arguments in favor of requiring --lt- options to come
first, but since (at the time) that would require simultaneously
patching the cwrapper to match as well, and we were trying to only
modify the sh-wrapper since the changes to it were so massive.

We could, now, perhaps modify BOTH the sh- and c- wrappers to require
the --lt- options to be first, but then Ralf's scenario concerning $TOOL
vs $TOOLFLAGS would break.

> Charles, $@ expansion in a loop is very slow with current bash
> <http://lists.gnu.org/archive/html/bug-libtool/2011-01/msg00007.html>
> which brings us back to the above argument.

Actually, I think the simple workaround above is more than sufficient
(*).  If there are NO --lt- options, then skip the whole mess...but if
somebody DOES pass --lt-*, then, well, it'll be slow.

(*) The only issue left is this: libtool actually uses --lt-dump-script
*explicitly* to generate the copy of the sh wrapper that is used for
"sourcing back in" -- but we ONLY do it this way if (a) host is cygming,
and (b) build == host.  If host is cygming but we're crossbuilding, then
we use func_emit_wrapper instead, as well as on other hosts.

This native cygming behavior is more historical than valuable, and
wasn't removed when the exe wrapper was modified to exec the target app
itself (rather than exec'ing the sh-wrapper, which THEN execed the
target app) out of some "cwrapper should eat its own dogfood" sense.
But...why can't we use func_emit_wrapper in both cases (and perhaps
remove --lt-dump-script entirely from both sh-wrapper and c-wrapper),
but /that/ would require a doc change, IIRC.

Anyway, if we changed libtool to use func_emit_wrapper instead of
--lt-dump-script, then the only time --lt-* options would be used is if
the end user *explicitly* wanted to use them; e.g. --lt-debug.  OK, so
that suddenly slows things down... This is probably OK.

--
Chuck