Re: autoconf 2.57b: locking fails over NFS

[Alexandre Duret-Lutz]

>>> "Paul" == Paul Eggert <address@hidden> writes:

[...]

 >> How about dropping flock() for a mkdir()-based lock?

 Paul> Then we'd have to clean up afterwards, and deal with recovering
 Paul> from system crashes, and so forth.

Yes :( maybe that's too late for 2.58.

 Paul> Sorry, I'm missing a bit of the big picture here.
 Paul> Is it that important to have a working lock?
 Paul> What programs are likely to be updating these files simultaneously?
 Paul> Is it that common to have contention?

>From a dependency point of view, the rules to build
'./configure', 'Makefile.in', and 'config.h.in' are independent.
So when people change configure.ac and run `make -j', that can
trigger simultaneous runs of autoconf, automake, and autoheader.
The problem is that all these tools eventually run autom4te, and
when two (or three) instances of autom4te try to update the
cache you see very weird things.  Hence we want to serialize
these autom4te runs.

(tests/makej.test, in Automake, used to exhibit the problem --
although not systematically)

-- 
Alexandre Duret-Lutz