From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31491 invoked by alias); 28 Dec 2002 21:22:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 31476 invoked from network); 28 Dec 2002 21:22:08 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by 209.249.29.67 with SMTP; 28 Dec 2002 21:22:08 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva2.cipe.redhat.com [10.0.1.156]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id gBSLLrY14563; Sat, 28 Dec 2002 16:21:53 -0500 Received: from free.redhat.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.6/8.12.6) with ESMTP id gBSLLqMK017331; Sat, 28 Dec 2002 19:21:52 -0200 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.6/8.12.6/Submit) id gBSLLn99017327; Sat, 28 Dec 2002 19:21:49 -0200 To: Michael Elizabeth Chastain Cc: dj@delorie.com, binutils@sources.redhat.com, drow@mvista.com, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name) References: <200212282057.gBSKva103446@duracef.shout.net> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Sat, 28 Dec 2002 13:44:00 -0000 In-Reply-To: <200212282057.gBSKva103446@duracef.shout.net> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00737.txt.bz2 On Dec 28, 2002, Michael Elizabeth Chastain 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