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)
