Re: [WIP] Fix HAVE_CONFIG_H -Wundef warnings.

[Roland McGrath <roland at hack dot frob dot com>]

> Roland,
> 
> Is fixing the HAVE_CONFIG_H -Wundef warnings as easy as this?

It's relatively easy, but this is not it.

Firstly, never ever use -D rather than #define unless you have a very
serious justification.  (It's hostile to incremental builds, since GNU
make does not track command line changes.)

We do have a config.h but it's already implicitly included for every
file.  libc-symbols.h does #include <config.h>, and every compile gets
libc-symbols.h via the -include switch.  So !HAVE_CONFIG_H is the
correct state for libc.

Our config.h does not have a multiple-inclusion guard.  OTOH, it so
happens that all the contents of config.h are things that are silently
harmless to repeat (#undef of things already #undef'd, #define of
things to the identical value already #define'd).

That being the case, it's already harmless to have it included more
than once--and it would also be harmless to give it a multiple
inclusion guard, unnecessary though that is.  But what's really right
is to have it included only once, which means just the existing once
via libc-symbols.h and never directly in any source file.

The obvious thing is to put "#define HAVE_CONFIG_H 0" right after
"#include <config.h>" in libc-symbols.h.  That won't do what we want
today, because there are many files that use #ifdef rather than #if
for the test.  Since any mention of <config.h> at all should only
appear in source files shared with other projects for their benefit,
it will require coordination to change them to #if and be sure that is
OK for the other users.  Conversely, if the projects that share these
files and care about config.h all use #ifdef uniformly, then we could
just change the small minority that use #if today to use #ifdef and
never define HAVE_CONFIG_H anywhere in the libc build.


Thanks,
Roland