From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28721 invoked by alias); 29 Dec 2002 06:42:24 -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 28696 invoked from network); 29 Dec 2002 06:42:23 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 209.249.29.67 with SMTP; 29 Dec 2002 06:42:23 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id gBT6g9d11387; Sun, 29 Dec 2002 00:42:09 -0600 Date: Sun, 29 Dec 2002 00:39:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200212290642.gBT6g9d11387@duracef.shout.net> To: aoliva@redhat.com Subject: Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name) Cc: binutils@sources.redhat.com, dj@delorie.com, drow@mvista.com, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com X-SW-Source: 2002-12/txt/msg00745.txt.bz2 Alexandre Oliva writes: > 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. In my humble opinion, yes. If you have a choice of options, make the default option be safe, and let people who want to go faster with risk of corruption specify additional options. Perhaps you think of "make -j" as an inherently unsafe option. In 1999 I would have agreed. In 2002 I think it's debatable. As time passes, I think it will become more and more important that it work without races. I build gcc about 50 times per week with automated scripts. Right now I use a single-processor machine. If I buy a multi-processor machine, I would like to just turn on "make -j" and have it work. When it doesn't work, I want all the bugs that I see to be real bugs that I can report to gcc-bugs and not have to check for cache corruption on every fail and not have people closing my bug reports with "might be cache corruption, don't use -j". I know other people run automated and semi-automated builds, too. > 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 agree that this is a trade-off. Obviously we disagree about what the right trade-off is. I think I've aired my viewpoint enough (it's kind of a simple view) so I'll rest here. Michael C