From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31083 invoked by alias); 15 Oct 2002 06:07:03 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 31071 invoked from network); 15 Oct 2002 06:07:00 -0000 Received: from unknown (HELO sngrel4.hp.com) (192.6.86.110) by sources.redhat.com with SMTP; 15 Oct 2002 06:07:00 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel4.hp.com (Postfix) with SMTP id 902FA36E for ; Tue, 15 Oct 2002 14:06:57 +0800 (SST) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 15 Oct 2002 16:06:43 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id TWW7HXB3; Tue, 15 Oct 2002 16:06:42 +1000 Received: from 16.176.68.120 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 15 Oct 2002 16:06:42 +1000 Received: from mbp by vexed.aus.hp.com with local (Exim 3.36 #1 (Debian)) id 181KpH-000696-00; Tue, 15 Oct 2002 16:05:07 +1000 Date: Tue, 15 Oct 2002 01:29:00 -0000 From: Martin Pool To: Neil Booth Cc: gcc@gcc.gnu.org, Zack Weinberg Subject: Re: gcc-3.2 -MD -o misbehaviour Message-ID: <20021015060504.GN14336@samba.org> References: <2683.198.102.182.67.1033413284.squirrel@mercury.axian.com> <20020930220940.GA1213@toey.sourcefrog.net> <4710.198.102.182.67.1033427430.squirrel@mercury.axian.com> <20020930234356.GA14232@samba.org> <62621.216.99.197.112.1033440272.squirrel@mercury.axian.com> <20021001060338.GE14232@samba.org> <2960.198.102.182.102.1033495681.squirrel@mercury.axian.com> <20021002053641.GC22443@samba.org> <20021014194429.GC32293@daikokuya.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021014194429.GC32293@daikokuya.co.uk> User-Agent: Mutt/1.4i X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B X-SW-Source: 2002-10/txt/msg00786.txt.bz2 On 14 Oct 2002, Neil Booth wrote: > Martin Pool wrote:- > > > The manual from Debian Sid's gcc-3.2 (3.2.1-0pre3) says > > > > If `-MD' is used in conjunction with `-E', any `-o' switch is > > understood to specify the dependency output file (but *note > > -MF::), but if used without `-E', each `-o' is understood to > > specify a target object file. > > > > But this doesn't happen: > > > > !1169 15:18 /tmp/test% ls -l > > total 4 > > -rw-r--r-- 1 mbp mbp 76 2002-10-02 14:44 hello.c > > !1171 15:18 /tmp/test% gcc-3.2 -MD -E -o hello.out hello.c > > !1172 15:18 /tmp/test% ls -la > > total 80 > > drwxr-xr-x 2 mbp mbp 4096 2002-10-02 15:18 . > > drwxrwxrwt 15 root root 49152 2002-10-02 15:17 .. > > -rw-r--r-- 1 mbp mbp 76 2002-10-02 14:44 hello.c > > -rw-r--r-- 1 mbp mbp 536 2002-10-02 15:18 hello.d > > -rw-r--r-- 1 mbp mbp 18019 2002-10-02 15:18 hello.out > > > > Actually I'm glad, this doesn't work. Overriding -o to specify the > > destination of dependency output seems needlessly complex since there > > is already -MF. Personally I'd prefer you pull this out of the > > documentation rather than making -o actually specify the output file. > > Yeah, it's a doc bug. The behaviour of -M and -MD with or without -o > and/or -E is kinda complicated and is different for almost each case; but > I believe that gcc != 3.0.x all agree behaviour, and there is some kind > of coherent underlying logic though it may not be obvious. I spent ages > with Chris Demetriou sorting this mess out. I would very much like you to keep it working as it actually does in 3.2, rather than as documented. At the risk of flogging a dead horse, here are some reasons against making -o specify the dependency output: - This breaks existing behaviour which distcc and possibly other programs or Makefiles depend upon. - Doing it that way denies a useful behaviour (producing both preprocessed source and dependencies), without adding anything useful in return. - The distcc client needs to generate both preprocessed source and dependencies, if the user wants dependencies. If "-MD -E" causes preprocessed output to go nowhere, then apparently the only possibility is to call gcc twice, which is wasteful. I think distcc is a useful program, and will be better in the future, so I hope the gcc team might pay a little attention to not breaking it. (I realize it's not your most important customer.) - The "intention" of the -MD option, as far as I can see, is to turn on a side-effect of cpp, rather than changing the whole action of the compiler (as -E does). To me (ignorant of the internals), generating dependencies as a side-effect makes a lot of sense. Interfering with -o changes the whole feeling of the thing. Making it sometimes a sideeffect and sometimes not sounds crazy. -- Martin Discontent Provider (please cc me on replies)