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

[Marc Espie <espie at quatramaran dot ens dot fr>]

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.

>The warning be improved to only report when a wrong header was
>actually found due to the user-provided change to the search path.
>However, I don't know if "randomly" kicking in (depending on exact
>port and system header, etc) is better than an absolute warning.

This is an area where too smart behavior can be very, very annoying.

There's nothing more annoying than knowing the compiler is wrong, in
one very specific case, for a whole large set of reasons, and being
unable to shup the compiler up.

If you keep the warning, give people a way to shut the warning down
completely, along the lines of `yes, I know what I'm doing, and stop
getting in my way.'

See, gcc ISN'T in charge of the operating system. And there are valid
reasons to do things in different ways (and the validity of those reasons
may be very relative to the community. Like, some BSD community may wish
to do things differently than the Linux crowd)

A set of headers can be a very complex things indeed. And the way headers
interact in complex systems can be a real maze.

I do spend a lot of time porting various software to OpenBSD.  And the most
annoying part of that job is working around various pieces of subtly broken
`automagic' software that assumes too much and needs to be shut up.

If gcc can be somewhat flexible and GET OUT OF THE WAY, it means it gets
easier for me to do that porting work.

And yes, I know what I'm doing. And even if I don't and you know better,
I don't have to care.  So either you give me the way to shut the warning
nicely, or I'll shut it brutally, by patching it out of existence all the
time.


And BTW, this configure trouble comes precisely from the fact that the
BSD mindshare is somewhat different: we bundle the compiler, so on our
systems, as the system compiler, it does NOT look under /usr/local.
Okay, it's not the behavior of the ports system. It's integrated in gcc
source (-DXXX_NATIVE), and if it ever were to disappear in the FSF sources,
rest assured it would stay in the BSD ports.

Woah... sorry if it sounds like a rant.