From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11978 invoked by alias); 28 Dec 2002 18:46:52 -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 11965 invoked from network); 28 Dec 2002 18:46:51 -0000 Received: from unknown (HELO delorie.com) (207.22.48.162) by 209.249.29.67 with SMTP; 28 Dec 2002 18:46:51 -0000 Received: from envy.delorie.com (envy.delorie.com [207.22.48.171]) by delorie.com (8.11.6/8.9.1) with ESMTP id gBSIkM817316; Sat, 28 Dec 2002 13:46:22 -0500 Received: (from dj@localhost) by envy.delorie.com (8.11.6/8.11.2) id gBSIkLP07491; Sat, 28 Dec 2002 13:46:21 -0500 Date: Sat, 28 Dec 2002 10:49:00 -0000 Message-Id: <200212281846.gBSIkLP07491@envy.delorie.com> X-Authentication-Warning: envy.delorie.com: dj set sender to dj@delorie.com using -f From: DJ Delorie To: aoliva@redhat.com CC: drow@mvista.com, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com, binutils@sources.redhat.com In-reply-to: (message from Alexandre Oliva on 28 Dec 2002 15:51:19 -0200) Subject: Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name) References: <20021228093127.GA455@doctormoo> <20021228163419.GA10686@nevyn.them.org> X-SW-Source: 2002-12/txt/msg00728.txt.bz2 > Unless... We could perhaps have NOTPARALLEL set by default, which > would take care of avoiding configurations in parallel even without > serialized dependencies, but a configure option to disable NOTPARALLEL > and introduce locking. DJ, how does this sound for you? I am not "vehemently" opposed to it. I've just seen, through experience, that there are lots of ways for it to go wrong. Serialized dependencies is a lot simpler and less error-prone (once we get them right, nobody's commented on my last suggestion). If we had a simple locking mechanism that worked on all the ext/nfs/dos/samba/etc/distcc filesystems we need to support, I'd be OK with it. I just think that people underestimate how much effort it takes to do locking reliably. The problem with NOTPARALLEL is that it shuts of *ALL* the toplevel parallelisms, including building A while configuring B, and testing in parallel. The toplevel Makefile really needs to allow parallel jobs to take advantage of the work we've done. We just need to be able to identify the parts that can't be done simultaneously, and somehow prevent those.