This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Michael Elizabeth Chastain <mec at shout dot net>
- Cc: dj at delorie dot com, binutils at sources dot redhat dot com, drow at mvista dot com, gcc-patches at gcc dot gnu dot org, gdb-patches at sources dot redhat dot com
- Date: 28 Dec 2002 19:21:49 -0200
- Subject: Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)
- Organization: GCC Team, Red Hat
- References: <200212282057.gBSKva103446@duracef.shout.net>
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