Gary V. Vaughan skrev 2011-11-28 10:20:
> 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
That's the evals in sub-shells, right? Those with this pattern:
if $_use_fast_funcs && (eval ...) 2>/dev/null
then
eval '...
or this:
if (eval ...) 2>/dev/null
then
eval '...
> 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.
I think you are underestimating the Cygwin fork pain.
BTW, libltdl runs libtool more like 20 times, but I agree it's very
small and the number of forks will not matter much.
My typical use case is "mid-sized" at a magnitude or so larger, and
even there with a fork rate of approx 10-15 Hz as I'm seeing, it wouldn't
be too harsh with a couple of extra forks - a minutes or so on the
wall clock time. But it would really add to the pain on some
(hypothetical?) large project with thousands of libtool invocations.
That's all I'm saying, but *I* am not building any of those...
Hmm, looking closer, shouldn't _use_fast_funcs have some kind of lt
prefix?
Cheers,
Peter
