Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Paolo Bonzini <bonzini at gnu dot org>]

Ismail DÃnmez wrote:
> Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab ÅunlarÄ yazmÄÅtÄ:
> > Ismail DÃnmez <ismail@pardus.org.tr> writes:
> > > That was just an example, real life testcase shows that problem stems
> > > from autoconf and its config.h. Projects end up defining things like
> > > HAVE_STDLIB_H twice which is not harmful at all but now causes an error
> > > if g++ is used.
> > Redefinitions with the same replacement list are not an error.
>
> Ok but that still doesn't cover the general use of
>
> #define PACKAGE_NAME foobar

We had to fix it ourselves for libffi as part of switching to autoconf 
2.50+.  The point is that installing config.h headers is broken by 
design -- and this is not something that the GCC community states.  See 
for example

http://www.cygwin.com/ml/automake/2000-10/msg00116.html

"Unfortunately, people are being lulled into a false sense of security,
because installing config.h appears to work while it is an uncommon
practice.  Things will go downhill fast if this becomes common
practice -- imagine the chaos that we would have if gtk.h indirectly
#included a raw (i.e. with rewriting prior to installation) config.h,
which set up a whole bunch of HAVE_foo macros and VERSION's that you
don't want to cope with when you use libgtk.  Even worse what if the
gnome headers installed another conig.h with overlapping and
contradicting macros...."

which warned about this already 8 years ago.  Sweet.

Why not fixing the handful of packages with a /^#define PACKAGE/d, 
instead of adding -fpermissive to the 50 users of those broken packages?
Paolo