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

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <200206112233.g5BMXmM30365@quatramaran.ens.fr> you write:

> 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.
[...]
> Woah... sorry if it sounds like a rant.

IMHO, that is OK.  I enjoy your view on the topic, but I think it is
from a perspective of someone that upgrades "the system compiler" not
from a user that installs a new version of gcc on his older OS
release.  The FSF release is obviously structured, by default, to
accommodate the later use more so than the former.  I.e. we put more
burden on the few people that can take it because they understand
subtle configuration issues instead of the masses that just want a
reasonable upgrade for their system.

[Neil asked for someone to defend the warning.  I will attempt to do
 so but I am mainly doing so only since I recall the arguments of the
 time and how it was resolved.  Also, because I usually attempt to
 keep my gcc user hat on while I patch gcc.  And, Mark has challenged
 all gcc developers to do so in the past.]

The issues are different and we need to also think about it
recognizing the difference in perspective.  I took me a while to
understand that some post from your perspective and others post from
the user perspective.  There is nothing wrong with it especially when
people are clear on which perspective they are coming from.  To
resolve the difference in perspective allow me to add more context to
my argument:

The warning is on by default in the FSF sources (at the moment at
least ;-) as people will obtain the sources and install them as an
non-vendor endorsed upgrades to their system (in that mode, it might
well "fix" or "supplement" your perfect system headers ;-).

If you make gcc your system compiler and don't fix headers (and/or did
it in place thus there is no parallel tree of headers), then as "we"
(i.e. I think this is just the party line on the matter) tell everyone
who uses gcc as a system compiler, you are free to change the compiler
as long as it is marked with different version information than would
be reported from an official FSF release...

It might well be that when installed as a system compiler, the warning
is not really helpful.  I am unwilling to judge that; but, then again,
I don't have to since you have final authority as a system compiler
guy for xBSD.  You have the right to brutally shut up that warning.

It might also cause more harm than good when configured from FSF
sources to uprgade a system compiler.  However, we are talking about
an *informational warning* here, not an error, right?

It is autoconf, in some configurations (since I have yet to ever see
it, I suspect that it must be a user-provided clause not default
autoconf-generated files), that is checking gcc with -I... and not
accepting/ignoring such warnings gracefully (granted, they were not
known to exist at the time the autoconf files were written - thus I
think we should attempt to help any maintainers of such packages fix
their usage).

Independent of that, Phil has clarified a *different* failure mode
with the warning.  He can reproduce the warning without the user
providing any -I switches.  I grant that would be mightly annoying.
Let us not mix Phil's case (I think it has to do with how he attempted
to install gcc) with the other that affects some autoconf-based projects.

But what am I missing about the autoconf case?  I have a fairly good
memory without studying the list on the matter but this is from
memory: We knew about that exact case when the change was made to FSF
gcc sources.  We knew that users of gcc that provided -I/usr/include
were doing something they may not have understood to cause other
cascading errors (i.e. thus the importance of the warning).

It seems a shame to have shipped a version that was designed to
encourage some users to clean up their act only to fall back and
remove a very useful warning...  (the bulk of the pain will have
already been paid by the time we release 3.1.1, thus removing the
warning now only allow errant -I uses to return unchecked)

Regards,
Loren

PS, none of this should be taken to point a finger at any project that
added -I/usr/include.  At the time they did so, it may not have been
as big a problem.  And the gcc manual may not have warned as strongly
about it or at all.