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