From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13565 invoked by alias); 27 Dec 2002 20:42:43 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13489 invoked from network); 27 Dec 2002 20:42:42 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by 209.249.29.67 with SMTP; 27 Dec 2002 20:42:42 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id MAA23480; Fri, 27 Dec 2002 12:42:26 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma023458; Fri, 27 Dec 02 12:42:03 -0800 Received: from casey.transmeta.com (casey.transmeta.com [10.10.25.22]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id gBRKg6327092; Fri, 27 Dec 2002 12:42:07 -0800 (PST) Received: (from dje@localhost) by casey.transmeta.com (8.9.3/8.7.3) id MAA05079; Fri, 27 Dec 2002 12:42:06 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15884.47902.892560.313412@casey.transmeta.com> Date: Fri, 27 Dec 2002 12:42:00 -0000 To: DJ Delorie Cc: neroden@twcny.rr.com, gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)") In-Reply-To: <200212271947.gBRJlK125992@envy.delorie.com> References: <200212271914.LAA04845@casey.transmeta.com> <200212271947.gBRJlK125992@envy.delorie.com> X-SW-Source: 2002-12/txt/msg00321.txt.bz2 DJ Delorie writes: > > Ugh. This is an effect of the configury change that > > I hadn't anticipated. This is going to be a major pain IMHO. > > > > Are the powers that be really ok with saying "just don't do that (*1)" ? > > I don't think this is really new - hitting ^C in the middle of a > configure before may have left you unreliable too, and target > configures were done during the build before. > > I think a better solution to support is documenting how to do a > partial configure/build without needing the ctrl-c. So that you'd > just say "make all-this all-that" and know that it's doing the right > minimal set of rules. PLEASE don't confuse my questioning of ^c wth my playing around with trying to get something working (*1) (instead of doing make all-foo install-foo). To me there are legitimate reasons why a developer would want "make ; ^c ; make" to work. S/he may have edited a file, typed make, and then said "Oh shit, I forgot something." Waiting for gdb to have to link (to pick something arbitrary that takes awhile to finish) before being able to go back and fix the problem is unacceptable (IMO of course). The existing target-configure case is a good argument. However, it is localized and recognizable. I can (or at least could) easily know when my ^c was going to screw something. The window appears to be MUCH bigger now. > The only way we could claim ctrl-c was reliable was is make itself > deleted the key files if that rule is interrupted. I don't think we > can rely on that being portable, but at least we could claim that for > makes that support that, we claim that it works reliably. Note that I'm not asking for 100% reliability. Rather, my impression is that reliability has gone from 90-ish% to 30-ish%. Blech. If by "key files" you mean "the target of the rule" I _think_ we're ok. Doesn't every make (that we care about) delete the target file if interrupted? (setting aside .PRECIOUS - heh, got to be a LOTR pun in there somewhere :-)). --- (*1): I'm sorry I mentioned it. I frequently use make all-foo. The point was to illustrate how I ran into "cd dir ; $(MAKE)" which is obviously a legitimate bug regardless of how it was tripped over.