Re: preprocessor/5153: #include path not affected by #line in cpplib

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

The following reply was made to PR preprocessor/5153; it has been noted by GNATS.

From: Neil Booth <neil@daikokuya.demon.co.uk>
To: John Marshall <jmarshall@acm.org>,
	Zack Weinberg <zack@codesourcery.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: preprocessor/5153: #include path not affected by #line in cpplib
Date: Tue, 18 Dec 2001 23:07:28 +0000

 John Marshall wrote:-
 
 > >Description:
 > In previous (i.e. non-cpplib) versions of GCC the dirname part of a filename
 > in a #line directive would affect the #include search path.  This is no
 > longer the case.  This is a change in behaviour compared to eg GCC 2.95.x.
 > >How-To-Repeat:
 > (This is not preprocessed output because the problem depends on separate
 > files and directories.)
 > 
 > [File 1: test/src/foo.h]
 > extern int foo ();
 > 
 > [File 2: test/build/foo.c]
 > /* A Bison parser, made from ../src/foo.y
 >    by GNU bison 1.30.  */
 > #line 1 "../src/foo.y"
 > #include "foo.h"
 > 
 > [File ends]
 > 
 > (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.
 
 Neil.