Re: Faster install for libtool outputs.

[Ralf Wildenhues]

Hi Jim,

* Jim Meyering wrote on Sat, Sep 20, 2008 at 02:02:36PM CEST:
> Ralf Wildenhues <address@hidden> wrote:
> >
> > One downside of the large test suite is the time it takes to complete.
> > Since there are lots of instances of $sleep in it, I've found it helpful
> > to use a munged version of coreutils' check.mk for running tests in
> > parallel.  Hmm, maybe that will push me to eventually finish its
> > inclusion into Automake proper.
> 
> If not, please share your munged check.mk patch.

Hmmyes, I think I will.  If you don't mind to wait another couple of
weeks, I'll try to at least clean up those issues I'm already aware of.
I'm kinda hoping that, if I don't get it in proper, then maybe we can
still distribute check.mk as an aux file in Automake, and then hint the
more adventurous users to try it out.

> I too find it hard to wait for the tests, and as such,
> sometimes do not even run them.  Especially with more and more
> multi-core systems these days, parallelizing is important.

Fully agreed.  Luckily often one can get away with running a subclass
of tests.

Besides parallel testing, I recently stumbled over the idea of running
'automake' threaded, so that some Makefile.in files can be created
concurrently when bootstrapping.  This seemed almost too trivial to be
true: you need to parse configure.ac stuff serially, then you can fork
worker threads, and treat all makefiles independently, except for the
one that distributes the aux dir files, it must come last.

That "trivial" ended when I hit a major knack: the code that deals with
Automake conditionals uses some trickery to compare conditionals by
their hash address, and uses circular pointery, too.  When spawning a
thread, somehow an inconsistency is introduced in the structures.
I have yet to get to the bottom of this.

I'll post details as I get to cleaning up the notes, I really don't want
to share my ugly late night testing hacks.

Cheers,
Ralf