From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29131 invoked by alias); 8 May 2002 17:36:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 29085 invoked by uid 71); 8 May 2002 17:36:01 -0000 Date: Wed, 08 May 2002 10:36:00 -0000 Message-ID: <20020508173601.29079.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Neil Booth Subject: Re: preprocessor/6521: -MG creates dependency with wrong path Reply-To: Neil Booth X-SW-Source: 2002-05/txt/msg00235.txt.bz2 List-Id: The following reply was made to PR preprocessor/6521; it has been noted by GNATS. From: Neil Booth To: Zack Weinberg Cc: Robert Spier , gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: preprocessor/6521: -MG creates dependency with wrong path Date: Wed, 8 May 2002 18:31:05 +0100 Zack Weinberg wrote:- > I'm not entirely sure I understand this. > > I've never really liked -MG; it is too inflexible. With <> it does > something fairly silly, as Robert points out; but with "" it does > something equally silly, which is to assume that splatting whatever > string the user provided into the dependency list will work. (It does > _not_ assume they live in the same directory as the source file; > consider split source and build trees. The current behavior is > more likely to work in practice than the documented one, but... Good point, I'd not thought of that. I tend to think, though, that -MG should never really be being used with <>, so whatever we do isn't that important. That makes me like Robert's patch as it deletes code, and does what is documented after all. > The behavior under discussion predates cpplib, incidentally. > > It seems to me that we should leave -MG alone, since there are > undoubtedly Makefiles out there depending on every last quirk of its > semantics (remember all the fallout the last time we decided to > improve the semantics of the -M switches?). We should instead come up > with a new way to do it that lets the user say where the generated > file is expected to turn up... perhaps -Mx puts all the > dependencies on generated files in . (Where 'x' is some > appropriate letter; I am too tired to think of a good one right now.) Hmm, I guess. We have too many options, really. It's a shame -MG can't die. Fancy doing it with your "closing same file twice" patch? 8-) > Come to think of it, -MG and -MP clash. We should mark entries added > to the list by -MG and not generate phony targets for them under -MP, > or Make will pitch a fit about multiple rules for the same target. You mean because the missing file presumably has a make rule specifying how to generate it elsewhere? Neil.