This is the mail archive of the
mailing list for the Cygwin project.
Re: suggestion for cygwin gcc-3.2
- From: "Gareth Pearce" <tilps at hotmail dot com>
- To: cygwin at cygwin dot com
- Date: Sat, 17 Aug 2002 05:49:15 +0000
- Subject: Re: suggestion for cygwin gcc-3.2
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.
Since you seem to have followed the gcc mailing list you will possibly know
I dont like this much either.
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..."
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.
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
times, because you want a certain header to trump the system default
I am thinking this would have to be pretty rare. But anyway.
It indeed looks pretty pointless on gcc ...
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.
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.
Join the world’s largest e-mail service with MSN Hotmail.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html