[Top][All Lists]

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

Re: Paralizing configure

From: Bob Friesenhahn
Subject: Re: Paralizing configure
Date: Thu, 10 Feb 2011 11:07:10 -0600 (CST)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

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.


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 "" 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'
( can serve as an example.

No, they can't, because they are not installed on unusual platforms by

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

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

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