libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool optimization


From: Michel Briand
Subject: Re: libtool optimization
Date: Wed, 22 Oct 2008 01:07:26 +0200

Ralf Wildenhues <address@hidden> - Tue, 21 Oct 2008 21:04:29
+0200

>Hi Michel, Bob,
>
>* Bob Friesenhahn wrote on Tue, Oct 21, 2008 at 05:26:58PM CEST:
>>
>> Current libtool still uses the shell that Autoconf chooses for it.  
>> However, if you have a faster shell which actually works (e.g. dash) you 
>> can specify it via the CONFIG_SHELL environment variable prior to  
>> running the configure script.
>
>Actually, you have to specify it twice, unfortunately:
>  CONFIG_SHELL=/bin/bash /bin/bash ./configure [OPTIONS...]
>
>As to which shell is best, it's not so clear as it might look at first.
>dash and ksh are faster than bash for some packages, but when it comes
>to large packages with many objects, the improved appending (var+=val)
>implemented in bash >= 3.2 really starts to make a difference, and other
>shells will be slower.
>
>Using vendor /bin/sh on, say, some AIX releases, is asking for trouble.
>That thing is seriously inefficient, in that for example the Autoconf
>testsuite will take days with /bin/sh, but only a couple of hours with
>a sane shell.
>
>Cheers,
>Ralf

Honestly I wanted to do two optimizations.

Firstly, I've tested /bin/dash and seen that it's much faster
than /bin/bash on my normal sized project.
->> is it possible to choose the shell in autogen ? That way users do
not have to bother to call configure like this ?

Secondly, I wanted to optimize the way gcc is called ? Why does libtool
need to create a shell snippet for all source files ? A Makefile that
simply calls gcc for each source file is much much faster ;))))

Michel

-- 

 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-    our own. Resistance is futile.

 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]