This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New cpp0 warning in 3.1 breaks configure (autoconf)


On Tue, Jun 11, 2002 at 07:11:48PM -0400, Phil Edwards wrote:
> On Tue, Jun 11, 2002 at 07:58:54PM -0300, Alexandre Oliva wrote:
> > On Jun 11, 2002, Marc Espie <espie@quatramaran.ens.fr> wrote:
> > > In article <200206112213.g5BMDp3L044244@latour.rsch.comm.mot.com> you write:
> > >> I think the current behavior is worth defending since skipping fixed
> > >> system headers can cause serve cascading problems that are hard to
> > >> debug by the user.
> > 
> > > Of course, this does assume the compiler and fixincludes are always right.
> > 
> > -I/usr/include is always wrong.  -isystem /usr/include might be
> > acceptable.
> 
> Let me throw out an idea:
> 
> Ignore -I/usr/include.  Silently, even.  Warn only if -Wfoo is given
> (for whatever value of foo).
> 
> More generally, ignore -I's of STANDARD_INCLUDE_DIR ("/usr/include"
> by default).  Or maybe, anything in the cpp_include_defaults array.
> Give a diagnostic only if the user asks for one, because otherwise there
> is nothing the user can do about it.
> 
> We can recover from parsing errors and continue.  Why can't we recover from
> command-line user errors and continue?

Heck, the warning I want to get out of all this are includes of what
STANDARD_INCLUDE_DIR and the equivalent for /usr/local/include would be
in a native compiler, when using a cross compiler.  Readline in the GCC
source tree does this sometimes, for instance.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]