Re: Paralizing configure

[Bob Friesenhahn]

On Tue, 8 Feb 2011, Marian Marinov wrote:

> Hello guys,
> After Ralf's talk at FOSDEM I'm really enthusiastic about autoconf
> paralization.

There are quite a lot of things to address before something exotic 
like parallelization is considered.

For one, configure usually chooses the slowest shell on the system. 
This happens to be a very popular GNU one.  It would be useful for 
that shell to run much faster, or for configure to work well with a 
shell which runs much faster.

If we can agree on minimal functionality required from the shell, then 
configure can be streamlined to run faster.

The configure script is still many times too large.  Configure scripts 
should not be 1MB (or more) in size.  Configure scripts seem to 
explode the scriptage by 10X what the user specified.  This is not 
necessary since common-bits can be versioned and formally installed. 
Devising ways to make the configure script smaller should help make 
the configure script run faster.

The actual tests which are performed (run compiler, linker, etc.) seem 
like they are only a fraction of the total time expended.

Lastly, a special "shell" designed to run only configure scripts would 
be quite useful since it could be very small, embeddable, and include 
extensions specifically for use by configure scripts.  For example, 
some of these extensions could implement autoconf intrinsics.

Extensible light-weight shells like 'rc' and 'es' 
(http://en.wikipedia.org/wiki/Es_shell) can serve as an example.

It takes about 1/4 of a second for 'autoconf' to produce a 1MB 
'configure' script for my project.  We should be seeing execution 
performance more like that (with consideration for running external 
build tools) from configure.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/