Re: Paralizing configure

[Bob Friesenhahn]

On Wed, 9 Feb 2011, Olaf Lenz wrote:
> On 02/09/2011 04:29 AM, Bob Friesenhahn wrote:
> > There are quite a lot of things to address before something exotic
> > like parallelization is considered.
>
> I must say I disagree with most of your points.

Good!

> Frankly, I do not really understand the fuzz about configure running for
> a few tens of seconds. After all, you usually have to do it only once if
> you are a user. If you are a developer, you have to run it only whenever
> a new file is added. Is that so much of a pain?

I agree it is not too painful for me.

> And about the size of the configure script of a few MB, is that really
> any problem in a time where we have GBs of memory and TB of hard disk space?

While configure scripts do compress well, consider that they are 
replicated in every tarball for the ten thousand or so packages that 
likely use autoconf and these packages are archived in thousands of 
locations.  While residing in the tarball, the configure script is 
aging and not benefiting from autoconf improvements.

> In fact, configure uses not the slowest, but the most ancient one, which
> is the simple Bourne shell, and even just a subset of that. And the

Configure usually just selects 'bash' if it is available on the 
system.  This shell is usually demonstrated to be the slowest shell 
implementation available at running large scripts.

> Installing some shell code snippets somewhere in the system may sound
> simple enough, but given the exteremely heterogenous Unix systems, it
> would be very hard to decide where to install them so that they can be
> definitely found by configure. Or would it be necessary to run a
> pre-configure step to determine the location of the snippets? :-/

This is true, but configure does manage to find the C compiler and 
tools like 'sed' so I think that this is a non-issue.  If it does not 
find these things, then the user must provide assistance.

I see little reason that "configure.ac" can't be used directly as the 
configure script.  Why are we distributing this bloody-large 'm4' 
output?

> The same as above, only worse. For this it would not only be necessary
> to install some shell code somewhere in the system, but you would
> furthermore have to port this new "shell" to any new platform. This is
> basically the approach of cmake. Cmake is nice if you can use a platform
> where cmake runs, but it doesn't run everywhere.

The requirements from the OS would be minimal so achieving portability 
is easier than for a program like GNU make.

> > Extensible light-weight shells like 'rc' and 'es'
> > (http://en.wikipedia.org/wiki/Es_shell) can serve as an example.
>
> No, they can't, because they are not installed on unusual platforms by
> default.

The source code for such tiny shells is much smaller than the 
configure script.  It can be bundled (like libtool) if desired.

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