Re: parallelized configure

[Alexander Holler]

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:

http://www.youtube.com/watch?v=C_zRngibGc8

with these slides:

http://www.gnu.org/ghm/2010/denhaag/slides-autotools-ghm-2010-talk.pdf

> 
> 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.

Regards,

Alexander Holler