This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: preprocessor/5153: #include path not affected by #line in cpplib
- From: Zack Weinberg <zack at codesourcery dot com>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 19 Dec 2001 00:16:01 -0000
- Subject: Re: preprocessor/5153: #include path not affected by #line in cpplib
- Reply-to: Zack Weinberg <zack at codesourcery dot com>
The following reply was made to PR preprocessor/5153; it has been noted by GNATS.
From: Zack Weinberg <zack@codesourcery.com>
To: Neil Booth <neil@daikokuya.demon.co.uk>
Cc: John Marshall <jmarshall@acm.org>, 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