From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8021 invoked by alias); 28 Dec 2002 18:34:54 -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 8006 invoked from network); 28 Dec 2002 18:34:53 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by 209.249.29.67 with SMTP; 28 Dec 2002 18:34:53 -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 gBSIYdY31752; Sat, 28 Dec 2002 13:34:39 -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 gBSIYcMK032763; Sat, 28 Dec 2002 16:34:38 -0200 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.6/8.12.6/Submit) id gBSIYcsC032759; Sat, 28 Dec 2002 16:34:38 -0200 To: Daniel Jacobowitz Cc: gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com, binutils@sources.redhat.com Subject: Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name) References: <20021228093127.GA455@doctormoo> <20021228163419.GA10686@nevyn.them.org> <20021228175919.GA17177@nevyn.them.org> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Sat, 28 Dec 2002 10:41:00 -0000 In-Reply-To: <20021228175919.GA17177@nevyn.them.org> 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/msg00726.txt.bz2 On Dec 28, 2002, Daniel Jacobowitz wrote: > It's a question of whether you can do the locking without making people > throw up, I think. I'm confident I can, but... On second thought, it occurs to me that all locking would accomplish is let one make in a make -j pool run one configure script while other makes block on the lock. Not good... Another idea is that we could really run multiple configure scripts in parallel, giving each one a separate cache file. We'd still have to synchronize the actions of taking a copy of config.cache and of updating it, and then we might get some tests run more than once in separate directories. But then, frankly... If running configure scripts in parallel is so much of a problem, why haven't we had problems so far? It's not like our build infrastructure has ever prevented configure scripts in sibling directories from running in parallel. It's perfectly possible for say gas, ld and binutils to be reconfigured in parallel after their configure scripts are modified, and I've never heard of anyone having problems because of this. So, if we really can't avoid the problem, is it really worth fussing so much about it? I mean, if you want to make absolutely sure that configure to be run sequentially, run `make configure' without -j and be done with it, and only then run `make -jN all NOTPARALLEL=all'. If you can live with a little bit of risk, skip `make configure' and let us know if you run into problems (after forced serialization of configure is taken out, of course :-) Comments? > You mean, like any config.status from any day before today? :) Yes, > that's what I meant. Sorry, it took me that long to figure out that's what you meant -- 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