From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17988 invoked by alias); 19 Dec 2001 00:16: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 17945 invoked by uid 71); 19 Dec 2001 00:16:01 -0000 Date: Tue, 18 Dec 2001 16:16:00 -0000 Message-ID: <20011219001601.17944.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Zack Weinberg Subject: Re: preprocessor/5153: #include path not affected by #line in cpplib Reply-To: Zack Weinberg X-SW-Source: 2001-12/txt/msg00987.txt.bz2 List-Id: The following reply was made to PR preprocessor/5153; it has been noted by GNATS. From: Zack Weinberg To: Neil Booth Cc: John Marshall , gcc-gnats@gcc.gnu.org Subject: Re: preprocessor/5153: #include path not affected by #line in cpplib Date: Tue, 18 Dec 2001 16:14:35 -0800 On Tue, Dec 18, 2001 at 11:07:28PM +0000, Neil Booth wrote: > > > > (In the real world, what we have is foo.y, foo.h in a source directory, > > and foo.c has been generated in a separate build directory from foo.y. > > Because most GNU projects put foo.c in the source directory, they haven't > > encountered the problem described, but that doesn't mean arranging builds > > like this is invalid.) > > Zack, is this limitation intentional or arbitrary? It seems having it > affect the path can be useful, but I worry about side-effects on > existing code. Then again, John says this was the historical behaviour. It was intentionally changed, but I do not remember why. If no one can point to code which is broken by the historical behaviour, it probably makes sense to change it back. Note that a simple -I../src will cause foo.h to be found again. zw