[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FreeBSD, autom4te and locking on NFS

From: Ralf Wildenhues
Subject: Re: FreeBSD, autom4te and locking on NFS
Date: Sun, 30 Apr 2006 08:43:46 +0200
User-agent: Mutt/1.5.11+cvs20060403

Hi Noah,

* Noah Misch wrote on Sat, Apr 29, 2006 at 05:35:01AM CEST:
> On Fri, Apr 28, 2006 at 11:52:58AM +0200, Ralf Wildenhues wrote:
> > - AFAICS this causes autom4te to continue but exit with an error status.
> You are correct, but I did not intend to make it do that.  We need to use a
> warning class, not an error.  I chose `unsupported'.

OK with me.

> >   The only difference with parallel make is that the message is
> >   adjusted.  Is that correct semantics?  Wouldn't it be safer to
> >   actually fatal() if we are running under parallel make?
> >   (Take this with a grain of salt; I don't know what I'm talking about.)
> Good question; yes.  I have changed the patch to do that.  Of the luxuries of
> `make -j' and broken locking, users may now pick one.

Yes, that sounds reasonable.

> > - BTW, is there real-world indication of build tools other than
> >   Automake-created Makefiles that may happen to invoke parallel autom4te
> >   instances, possibly indirectly?
> By appearances, the sample makefile content in documentation node `Automatic
> Remaking' can run autoconf and autoheader in parallel.  I do not know how many
> people have copied it.

Well, that would be fine: lock() would detect it with MAKEFLAGS.
My question was posed wrongly: is there real-world indication of
build tools other than `make' that may happen to invoke more than
one instance of autom4te, possibly indirectly, at the same time?
(Because the MAKEFLAGS works independently of whether the Makefile
was written by Automake or by other means.)

> Here is an updated patch.  What do you think?

Looks good to me.  Alexandre?

Cheers, and thank you!

> 2006-04-28  Noah Misch  <address@hidden>
>       * lib/Autom4te/XFile.pm (lock): Allow EOPNOTSUPP, besides ENOLCK.  Only
>       mention `make -j' when applicable.  Only raise fatal errors when `make
>       -j' is involved.  Improve error message.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]