Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Gary V. Vaughan]

Hi Peter,

On 8 Dec 2011, at 20:40, Peter O'Gorman wrote:
> On 12/08/2011 04:21 AM, Gary V. Vaughan wrote:
>> The recently pushed series of patches included the controversial
>> introduction of an additional 3 forks per invocation, which might
>> add a minute or two of wall-clock time to giant builds on windows.
>> By assuming that windows will run shell scripts on some shell with
>> all the modern optional features that libtool wants, this patch
>> eliminates even those 3 new forks.
>> 
>> Okay to push?
> 
> The whole reason these checks were done in configure and not in libtool was 
> to avoid these forks, and the slow down involved. We did a lot of work at 
> speeding up libtool so that non-portable tools such as dolt would not be 
> necessary, including moving large chunks of compile mode script closer the 
> the top of libtool so that it would execute faster.

Ack.  However since I wrote all the hairy M4 code to do the configure time 
replacements, I've changed my mind about how well they work in the grand scheme 
of things... The usual mode of integrating libtool is to have your project's 
configure build a libtool script, which you then call as a compiler wrapper.  
With the exception of projects with a huge number of tiny files to compile, I 
seriously doubt that 3 additional forks per invocation would be noticable as it 
stands now, and after looking back through the replacement code I recently 
expunged, we probably save a few hundred forks from sed and perl invocations at 
configure time, which would mean you don't get any slow down overall in a 
'./configure; make; make install' sequence until you've invoked the libtool 
script at least several dozen times.

Also, I'm trying hard to make hacking on libtool much less infuriating to 
attract more outside patches and development.  Having configure switch out 
function definitions is an odd thing to do, and libtool is already hard enough 
to understand without having to worry about having configure rewriting some of 
libtools functions... hopefully it doesn't make any mistakes ;)

> Any additional forks will slow down the script and should be avoided on all 
> platforms.

Agreed.  And using a BASH_VERSION test will get us a good way there.  I'll also 
work on a follow up patch to set the new lt_HAVE_XSI_OPS and friends using the 
existing machinery for injecting configure time variables into libtool, so I 
can also throw out the last couple of M4 replacement macros.

> Simply removing $(SHELL) from the LIBTOOL variable should fix the bug that 
> this is attempting to fix, without slowing down libtool.

But then we go back to having bug reports about libtool not getting an execute 
bit.  I'm not in favour of making that change.

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