From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13164 invoked by alias); 28 Dec 2002 18:49:03 -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 13152 invoked from network); 28 Dec 2002 18:49:02 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 28 Dec 2002 18:49:02 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18SNtN-0004OQ-00; Sat, 28 Dec 2002 14:49:09 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18SM2B-0005md-00; Sat, 28 Dec 2002 13:50:07 -0500 Date: Sat, 28 Dec 2002 10:50:00 -0000 From: Daniel Jacobowitz To: Alexandre Oliva 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) Message-ID: <20021228185007.GA22186@nevyn.them.org> Mail-Followup-To: Alexandre Oliva , gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com, binutils@sources.redhat.com References: <20021228093127.GA455@doctormoo> <20021228163419.GA10686@nevyn.them.org> <20021228175919.GA17177@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00729.txt.bz2 On Sat, Dec 28, 2002 at 04:34:38PM -0200, Alexandre Oliva wrote: > 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? Now you're speaking my language. This even lets me say "make configure-gdb" to configure exactly the directories I need. Sure, some reconfigures may end up taking place in parallel; I posit that if we see a config.cache problem then it should be solved by fixing _autoconf_ to update the cache atomically. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer