Add warnings for #directives with indented #
Kaveh R. Ghazi
ghazi@caip.rutgers.edu
Mon Apr 3 13:52:00 GMT 2000
> From: Zack Weinberg <zack@wolery.cumb.org>
>
> On Mon, Apr 03, 2000 at 11:50:16AM -0400, Kaveh R. Ghazi wrote:
> > > From: Zack Weinberg <zack@wolery.cumb.org>
> > >
> > > On Sun, Apr 02, 2000 at 10:44:25AM -0400, Kaveh R. Ghazi wrote:
> > > > One more thing, bootstrapping gcc gives some of these warnings which
> > > > I think should be avoided.
> > > > Why isn't gcc/include being treated as a [system] include dir
> > > > in the above?
> > >
> > > Because the system include dirs are hardwired by pathname. It'll be
> > > a system include dir after installation.
> ...
> > I don't think we need Makefile hackery, this is a more general
> > problem. I would have thought that the -B flag would pass -isystem to
> > cpp. (All of these cases got a -B right?)
>
> -B./ does not automatically translate to -isystem ./include and I
> don't think it should. There may not be a ./include, or it may
> contain something you don't want to use.
Well, the docs contradict you. :-) From invoke.texi:
> @samp{-B} prefixes that effectively specify directory names also apply
> to libraries in the linker, because the compiler translates these
> options into @samp{-L} options for the linker. They also apply to
> includes files in the preprocessor, because the compiler translates
> these options into @samp{-isystem} options for the preprocessor. In this
> case, the compiler appends @samp{include} to the prefix.
Surely you agree that -B./ must at least translate into -I./include ?
If so, it makes perfect sense to mark ./include as a system header dir
because these files are either gcc supplied system headers or platform
"fixed" system headers. So -isystem is entirely appropriate.
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions
More information about the Gcc-patches
mailing list