Idea: Splitting up config header

[Phil Edwards <phil at jaj dot com>]

As we add AC_DEFINEs to the configury, 'autoheader' makes certain that
we add the needed lines to config.h.in.  The current config.h.in contains
HAVE_foo's for multiple possibilities, all jumbled together:

    1) header macros used only while building libstdc++
    2) header macros used only while using libstdc++
    3) header macros used while both building and using libstdc++
    4) header macros used only while testing libstdc++
    5) header macros never used

(1) through (3) are entangled -- think "Gordian Knot" -- and I've no plans
to try and fix that.

I propose splitting (4) out into its own header.  It's a whopping five,
count them, five macros.  But it will point the way for other work along
the same lines.

I propose splitting (5) out into its own header.  If you're wondering,
"why do we name macros in config.h.in which will never be used?" the answer
is, we didn't, autoheader added them.  See, in addition to adding all the
macros that we define ourselves, autoheader also adds macros which autoconf
defines for us whether we {need,use,want} them or not.

They're not dangerous to us, but users -- repackagers, especially --
might see them in the installed c++config.h and think that they describe
correct information.

The reasoning behind giving (5) an explicit header file which is never
ever used:  if autoheader thinks it needs to add macros, it will always
add them to the same file.  We give autoheader a fake target.  This keeps
autoheader happy, keeps unnecessary macros out of our actual headers, and
lets autoheader remain useful.  We could just stop running autoheader,
but it does catch mistakes.

So, instead of AC_CONFIG_HEADER(config.h), we have

    AC_CONFIG_HEADERS([junk.h config.h testsuite/testsuite_config.h])


Downside:  when adding a new AC_DEFINE, the hacker must add the macro to the
appropriate config header .in file, instead of simply running autoheader.
Alternatively, run autoheader, take the changed lines from junk.h.in, and
put them in the appropriate header.  It won't be not quite as convenient
as it is now -- one additional step -- but the gain is worth it IMO,
and adding AC_DEFINEs is a rare activity.

I've been using the above setup for about a week now, and intend to go
forward with it unless there are strenuous objections.


Phil

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan