delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2002/08/17/01:49:26

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Originating-IP: [203.26.31.119]
From: "Gareth Pearce" <tilps AT hotmail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: suggestion for cygwin gcc-3.2
Date: Sat, 17 Aug 2002 05:49:15 +0000
Mime-Version: 1.0
Message-ID: <F183SrNrGY868KMd6TZ0001435e@hotmail.com>
X-OriginalArrivalTime: 17 Aug 2002 05:49:16.0253 (UTC) FILETIME=[D279F0D0:01C245B1]

>This may generate some flames, so flame away if you want to.

I was expecing some too - but, no replys at all - huh i better fix that.

>
>I don't know about anyone else, but there is one particular "feature"
>of the new gcc that is driving me crazy.  I refer to:
>
>"warning:  changing search order for system directory..."
Since you seem to have followed the gcc mailing list you will possibly know 
I dont like this much either.

However...

>
>which appears if you redefine the system include directory.  Many
>times this isn't intentional as you may have an autotool macro which
>inadvertently does this for you.  Sometimes you may want to use an
>explicit include search path because you are cross-compiling.  Other
I'l take your word on this - only things i have heard about cross-compiling 
is that overiding the system include directory is Bad, to me it would sound 
like the cross-compiler isnt set up properly if your wanting to over-ride 
the system include header.

>times, because you want a certain header to trump the system default
I am thinking this would have to be pretty rare. But anyway.

>header.  To the autotools, such a warning will cause a c preprocessor
>test to fail.  This is highly aggravating, as it adds yet another
>unknown to the equation when you are porting packages.  Also, it
>makes tracking potential issues harder because it clutters the screen
>with useless garbage.  I mean, dangnabit, if I wanted a pedantic
>level of warnings, I would say so with -pedantic.  This warning has
>no business being in the default warning level, for the
>aforementioned reasons.  I know that passing "-w" will disable it,
>but that also disables the warnings which are actually useful.
>Therefore, I suggest that this warning be disabled by default and
>enabled only on a stricter warning level.  I ask here because I know
>it is useless to ask on the gcc list - seeing as how they're going to
>do it their way and the rest of us be damned.  If you need a patch, I
>will provide one.
It indeed looks pretty pointless on gcc ...

However If cygwin is going to change this, I would of hoped that we would of 
gone for one of the other approaches suggested.  Specifically I thought that 
a system with:
1. If -I is specified for system directory ignore the -I completely.
2. If -fallow-header-override - ignore rule 1 and dont warn.
3. If -Wheader-override - warn - in both case 1 and case 2.

This is a little bit more complex, but seems 'the right thing to do' after 
having read all the gcc arguments back and forth.


Gareth

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019