Serialization dependencies muck up configure-on-demand

[Alexandre Oliva]

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