From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14504 invoked by alias); 25 Mar 2008 21:04:52 -0000 Received: (qmail 14494 invoked by uid 22791); 25 Mar 2008 21:04:51 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 25 Mar 2008 21:04:34 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m2PL4WDL019597; Tue, 25 Mar 2008 17:04:32 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m2PL4WxZ015800; Tue, 25 Mar 2008 17:04:32 -0400 Received: from opsy.redhat.com (vpn-14-254.rdu.redhat.com [10.11.14.254]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m2PL4VZc014876; Tue, 25 Mar 2008 17:04:32 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 663EF3780C2; Tue, 25 Mar 2008 14:08:52 -0600 (MDT) To: Ralf Wildenhues Cc: Paolo Bonzini , Gcc Patch List Subject: Re: Patch: automatic dependencies for gcc References: <47E3E979.7020904@gnu.org> <47E89A0C.50607@gnu.org> <47E91C7E.8060506@gnu.org> <20080325202425.GD18200@ins.uni-bonn.de> <20080325204043.GE18200@ins.uni-bonn.de> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Wed, 26 Mar 2008 02:08:00 -0000 In-Reply-To: <20080325204043.GE18200@ins.uni-bonn.de> (Ralf Wildenhues's message of "Tue\, 25 Mar 2008 21\:40\:44 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-03/txt/msg01538.txt.bz2 >>>>> "Ralf" == Ralf Wildenhues writes: Ralf> As a really minor note, if you can make it two separate command lines Ralf> (instead of '$(COMPILE) ... && mv ...') you'll be able to avoid a Ralf> subshell (Automake 1.10 does this). Yeah. I see that we have this same bug in libcpp, but nobody ever noticed. So maybe I can finally stop panicking about this awful patch. I'm thinking the best thing might be to try to get rid of the uses of $(COMPILE) in config/ and instead run everything through the pattern rules in the top Makefile. This requires some other changes though. Ralf> IOW: why would atomic creation of the file listed by -MF be a Ralf> backward incompatibility, except maybe for the issue that a Ralf> fixed gcc is difficult to detect with a feature test? Yeah, I suppose atomicity by itself is just fine. But to fully eliminate this extra 'mv' we'd also have to not write the file on compilation failure. I think that means that there would be some cases where today's gcc writes a dependency file, but the new gcc does not -- and I am concerned that someone may expect that the file always exists. It is hard to say whether this is really worth worrying about. But, it is also hard to know what people out there depend on. As a silly example of this, I recently discovered that both config.guess and libtool parse the output of "ld --help". That sort of thing is why I default to conservatism here. Tom