Re: (toplevel) introduce host subdir configuration in Makefile

[Alexandre Oliva <aoliva@redhat.com>]

On Dec  2, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:

>> This was a bug in autoconf 2.13, that's fixed in autoconf 2.5x.

> What was?  The way files are generated from config.status?

Yup.  Each run of config.status uses a different temporary file name.

> Without atomic updates you will definitely lose some updates to the
> cache; since the cache is read once and written once.

Even with atomic updates, you lose some of them, unless the cache is
reread just before it's written back.  Currently, configure reads it
when it starts, and rewrites it when it finishes.  If you start
multiple configures using the same cache in parallel, the last one to
write its cache out wins, as long as you're not sufficiently unlucky
to have both of them doing it at the same time, in which case you may
end up with a corrupted cache file.

> I'm more worried about two configures writing to the cache at the same
> time.  Start both cat processes and you could end up with the two cache
> files interleaved at 1K blocks (or so, depending on FS/OS).  That makes
> me really uncomfortable...

Yup, this can be a problem.

The only safe solutions for this at the moment are to use separate
cache files per subdirectory (which defeats most of the purpose of the
cache) or prevent concurrent configure runs (which defeats the point
of making configure parallelizable)

FWIW, we've had target configures running in parallel for a long time,
and I don't know of any corruption caused by this.  Granted, there
aren't as many target libraries to be configured as there are host
packages, but still...

One way to try to overcome this limitation in autoconf that has just
occurred to me is to offload the updating of a shared config.cache to
the top-level Makefile.  E.g., the Makefile safely copies the
top-level config.cache to a subdirectory before it configures it, and
safely copies it back (or merges it) with the top-level config.cache
when configure finishes.  Safety can be accomplished with

cp ${cache_file} subdir/config.cache
run configure in subdir, with --config-cache=./config.cache
mv subdir/config.cache ${cache_file}

trying to merge the contents can get trickier, but I believe it can be
done too.

The one thing we'd have to be careful about is in case the user
specified a config.cache to the top-level, especially /dev/null.  We
may have to handle that especially, like autoconf does.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer