From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16825 invoked by alias); 27 Dec 2002 19:47:51 -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 16790 invoked from network); 27 Dec 2002 19:47:49 -0000 Received: from unknown (HELO delorie.com) (207.22.48.162) by 209.249.29.67 with SMTP; 27 Dec 2002 19:47:49 -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 gBRJlLx26741; Fri, 27 Dec 2002 14:47:21 -0500 Received: (from dj@localhost) by envy.delorie.com (8.11.6/8.11.2) id gBRJlK125992; Fri, 27 Dec 2002 14:47:20 -0500 Date: Fri, 27 Dec 2002 11:47:00 -0000 Message-Id: <200212271947.gBRJlK125992@envy.delorie.com> X-Authentication-Warning: envy.delorie.com: dj set sender to dj@delorie.com using -f From: DJ Delorie To: dje@transmeta.com CC: neroden@twcny.rr.com, gdb@sources.redhat.com, binutils@sources.redhat.com In-reply-to: <200212271914.LAA04845@casey.transmeta.com> (message from Doug Evans on Fri, 27 Dec 2002 11:14:42 -0800) Subject: Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)") References: <200212271914.LAA04845@casey.transmeta.com> X-SW-Source: 2002-12/txt/msg00320.txt.bz2 > 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. I would be amenable to altering the makefiles to delete key files on failure, to ensure they get rebuilt the next time around. But a ctrl-c interrupt would skip that step as well, so I don't see how we could do that reliably. The best we can do is keep the window of misopportunity limited creating the key files only as the last step. I.e, move in place after complete rather than redirect to the final file. Autoconf already works mostly this way. 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.