Re: Paralizing configure

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Thu, Feb 10, 2011 at 09:09:15PM CET:
> End of brain dump.

Addendum:

One of the prerequisites of threaded tests is getting intermingled
output right.  In fact, this is interesting even today, in packages
like GCC where multiple configure scripts may run at the same time:
In that case, one often sees
  checking for foo...
  checking for bar.h... yes
  no

There should be a way (command-line argument or so) to get configure
to only print complete lines once some test has finished.  (An
alternative would be to let only the master thread print output, but
that tends to be slower and less helpful in error cases.)

This, too, is more tricky than it seems, with all the ways developers
come up to nest tests and messages.  Luckily, it is not needed to get
it done perfectly, even incremental changes help.


In the AC_PARALLEL_UNSAFE case that I described, it is still necessary
that all macros called (directly or indirectly through AC_REQUIRE) are
fit for parallel execution: they all need to advertise the variables
that they set.  I'm not sure if it is possible to verify this
programmatically at M4 time.


Parallelization will probably hurt a cached rerun very badly, unless we
manage to *not* fork when the respective cache variable(s) have been
set.  On fast systems, cached reruns can finish in a couple of seconds
even for fairly large configure scripts like the coreutils one.  Adding
more than a few forks to that will be noticeable.


Cheers,
Ralf