On Thu, Jan 28, 2021 at 2:16 PM Bob Friesenhahn <bfriesen@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 28 Jan 2021, Zack Weinberg wrote: > > > > The main reason I can think of, not to do this, is that it would make > > the locking strategy incompatible with that used by older autom4te; > > this could come up, for instance, if you’ve got your source directory > > on NFS and you’re building on two different clients in two different > > build directories. On the other hand, this kind of version skew is > > going to cause problems anyway when they fight over who gets to write > > generated scripts to the source directory, so maybe it would be ok to > > declare “don’t do that” and move on. What do others think? > > This is exactly what I do. I keep the source files on a file server > so that I can build on several different types of clients. This used > to even include Microsoft Windows clients using CIFS. Do you use different versions of autoconf and/or automake on the different clients? > The lock appears to be taken speculatively since it is taken before > Autotools checks that there is something to do. ... > The most common case is that there is nothing for Autotools to do > since the user is most often doing a 'make' for some other purpose. It looks to me like the lock is taken at exactly the point where autom4te decides that it *does* have something to do. It might be possible to change it to take a *read* lock first and only upgrade to a write lock if new files are to be added to the cache, but Make shouldn't be running the autotools at all if they have nothing to do (which I suppose takes us over to the *other* thread about your problems with automake and configure's dependencies :-) zw
