[Top][All Lists]

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

Re: parallelized configure

From: Alexander Holler
Subject: Re: parallelized configure
Date: Wed, 15 Jan 2014 05:12:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Am 15.01.2014 01:20, schrieb Bob Friesenhahn:
> On Tue, 14 Jan 2014, Alexander Holler wrote:
>> I just was curious if there was some progress on that topic besides
>> what Ralf Wildenhues seemed to have tried out.

Btw. I haven't found a recording of his talk at FOSDEM 2011, but I
assume it was similiar to that one:

with these slides:

> The most challenging aspect is because configure scripts have a huge
> amount of dependencies (e.g. shell variable definitions) which only work
> due to the sequential nature of the script.  In order to parallize
> configure, one would need to somehow assure that results are available
> in the correct order.  Such logic is normal in make files but not in
> shell scripts.
> Part of configure scripts is written by the developers of a package and
> not from Autoconf and Autoconf has no way to predict the behavior of
> code which is outside of its control.

Sure, people do all kind of stuff in build systems. But a lot of tests
which do fly by when configure is called do look like taken from a
standard repository. And many of those tests are pretty simple and
without any dependencies.

> Regardless, configure scripts are not actually the main problem with
> package build times on modern hardware.  The main problem is that most

Depends on what you call modern hardware. If you build e.g. Squid (the
proxy) on some ARM while using a sd-card, it isn't really fast. Of
course, it's questionable if such a system would benefit a lot from
parallelized configure tests, but I still would assume such.

> free software packages are not constructed correctly so that they can
> take advantage of parallel builds.

Hmm, I'm using the parallel feature from gnu make very successful since
ext4 with support for nanosecond timestamps appeared (so since many
years). Without a fs with high resolution timestamps I had a lot of
problems, but with high resolution timestamps it works most of the time
like a charm.


Alexander Holler

reply via email to

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