Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time.

[Gary V. Vaughan]

Hi Peter,

On 28 Nov 2011, at 15:48, Peter Rosin wrote:
> Gary V. Vaughan skrev 2011-11-25 09:57:
>> Determine, on a function by function basis, what XSI features
>> are available in the shell that is actually running the script,
>> rather than the one that was picked at configure time by the
>> re-execution engine.
> 
> Doesn't this mean that the libtool script will do a number of
> extra forks each time it is run?

Well, yes and no.  There will be an extra 4 or 8 evals (depending
on whether the XSI function is chosen) as libtool starts up when
compared to 2.4.2, but the fast_funcs will each save a fork or
two on every invocation compared to if libtool configure found a non-
XSI shell when libtool was installed.  However, don't forget that
almost always, libtool is generated by the configure script of the
project that uses it, and the loss of seds, evals, and file renames
at configure time to splice in the fast_funcs most likely means
you'll be at a net win on total execution time for at least a couple
of dozen libtool invocations.

And let's not forget this actually fixes a bug... we've had reports
of configure re-execing with a good shell (say /opt/bin/bash) and
substituting in the XSI fast_funcs, but the libtool script doesn't
have all the slow re-exec machinery and runs with /bin/sh which then
chokes on the XSI extensions spliced in to libtool, unless the
caller manually sets SHELL and CONFIG_SHELL in their environment
before calling make (which is a bad idea for other reasons).

>  If that's the case, I would like
> to know how that impacts the execution time on Cygwin/MinGW...

I don't have access to Windows so I can't actually measure it, but
I doubt that the difference will be noticeable for even a large
project, and quite possibly a small project like libltdl that only
runs libtool a hand full of times will actually be (imperceptibly)
faster.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)