handling of config #defines

["James L. Dein" <jdein at windriver dot com>]

In the process of streamlining the configuration info for various
VxWorks and VxWorks AE targets we are running into an ordering
problem.  For example, for rs6000 we would like to use a single
target-configuration file, config/rs6000/vxppc.h.  Then, in
configure.in, we cause either config/vxworks.h or config/vxworksae.h
to be prepended to tm_h depending on the OS in the target triple.
These OS-specific .h files #define, among other things, OS-specific
macros that can be used, if necessary, in the target-specific files.

This approach fails for power-pc and certain other targets.  For
example, vxppc.h was designed long ago on the assumption that it was
to be like Sys V.4, only "just a little different."  So, at the very
top it #includes rs6000/sysv4.h, which in turn #includes
rs6000/rs6000.h.  All this makes sense because the Embedded ABI for
Power PC is based mainly on the Sys V.4 ABI.  Unfortunately (for
example) vxworks.h (but not vxworksae.h) needs to #undef
ASM_WEAKEN_SYMBOL, a macro which then then gets re-#define'd in
rs6000/sysv4.h.  This is just the tip of a small iceberg.

So, my question is this: what is the most "cleanly" way of dealing
with this problem?  One uncleanly way would be to conditionally simply
re-#define ASM_WEAKEN_SYMBOL in vxppc.h.  Doing so, however defeats
the goal of encapsulating the OS-dependent info in the OS-specific
files.

A more cleanly way, IMHO, would be to modifiy rs6000/vxppc.h so that
ASM_WEAKEN_SYMBOL, and certain other macro #define's, are wrapped in
#ifndef's.

Jim Dein