Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)

[Alexandre Oliva <aoliva@redhat.com>]

On Dec 28, 2002, Michael Elizabeth Chastain <mec@shout.net> wrote:

> To me, a race is a race.  Just don't have them in the first place and no
> bugs will creep in.

We don't have them by default.  We only have them if the user chooses
to make -j.  /me thinks that, if one wants to use make -j, one should
tell configure so, such that arrangements can be made to prevent the
nasty race condition at all costs.

The cost of serializing sub-configures is that it defeats most of the
niceties of having moved sub-configures into the Makefile: why should
you have to wait for gcc's configure to complete if what you want to
build is gdb?  Or, why should I wait for all of tcl, tk, expect, etc,
to build gcc?  With serialized dependencies, one of us will lose.

Should we penalize everybody just because some might want to make -j
and make it absolutely sure that they won't have any risk whatsoever
of cache corruption and they won't miss any opportunities for caching
test results.  Couldn't we instead ask these to pass an argument to
configure such that will make sure their requirements are satisfied,
while optimizing for most who aren't doing parallel builds, or can
take the negligible risk of cache corruption, or don't care about
potential loss of sharing of cache results, but who want to benefit
from the ability to configure only the packages that matter for them.
Are we really doing the right trade off?

> I would also prefer no locks, because I don't want to deal with locking
> mechanism headaches when a user with, say, an SMP Irix NFS client and
> an HP/UX NFS server has funny build problems.

Oh, shell locking is an entirely different matter.  It's based on the
atomicity of hard-linking or directory creation, with my preference
leaning towards the latter just because it's more portable.

-- 
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