This is the mail archive of the
automake@gnu.org
mailing list for the automake project.
Re: make -j and touching configure.in, with automake
- From: Akim Demaille <akim at epita dot fr>
- To: Alexandre Duret-Lutz <duret_g at lrde dot epita dot fr>
- Cc: Automake List <automake at gnu dot org>
- Cc: gnits at gnits dot org
- Cc: Aharon Robbins <arnold at skeeve dot com>
- Date: Wed, 07 May 2003 12:34:24 +0200
- Subject: Re: make -j and touching configure.in, with automake
- References: <200303311536.h2VFacBR024362@localhost.localdomain><mv4y92vplml.fsf@nostromo.lrde.epita.fr><2003-04-06-23-11-45+23129+duret_g@lrde.epita.fr><2003-04-07-00-49-03+23393+duret_g@lrde.epita.fr><mv4adf2oj5t.fsf@nostromo.lrde.epita.fr><2003-04-07-20-21-26+26526+duret_g@lrde.epita.fr>
>>> "Akim" == Akim Demaille <akim@epita.fr> writes:
adl> [...]
adl> Oops. I think autom4te should lock its cache when it runs, to
adl> cope with concurrent runs of overlying tools.
Akim> Indeed, why not. But then, what should it do when it
Akim> finds out there are several competitors?
adl> Wait for the lock. Am I misunderstanding the question?
I was wondering whether trying to be smart (i.e., locking only during
an actual writing) would be better as opposed to locking during the
whole process. I chose (with you agreement) the latter. Aharon,
using CVS Autoconf and CVS Automake you should 1. no longer experience
this problem, 2. have faster updates of the tree when touching say
configure.ac.