This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Serialization dependencies muck up configure-on-demand
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: drow at mvista dot com, gcc at gcc dot gnu dot org, neroden at gcc dot gnu dot org
- Date: 23 Dec 2002 19:28:32 -0200
- Subject: Re: Serialization dependencies muck up configure-on-demand
- Organization: GCC Team, Red Hat
- References: <20021223182335.GA17240@nevyn.them.org><200212231833.gBNIX4o14365@greed.delorie.com>
On Dec 23, 2002, DJ Delorie <dj@redhat.com> wrote:
>> Do we need the serialization dependencies?
> We need to make sure that no two configures run at the same time. If
> you can figure out a better way to do that, please do.
We can use shell locking (*) in the top level to make sure no two
configures run at the same time, if we really need that. Serialized
dependencies are exactly the wrong way to solve the problem, IMO. I
hadn't realized they had been implemented like that, otherwise I'd
have objected.
(*) attempt to create a directory say configure.lock and sleep until
creation succeeds, then run sub-configure, then rmdir it. This can
fail in the rare advent of the build directory being on an unreliable
NFS server, such that the reply of mkdir fails to get to the client,
that retries the operation and then gets a failure because the
directory now exists. We can probably live with that.
--
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