foo_TARGET_ARCH, foo_TARGET_OS problems
Simon Marlow
simonmar at microsoft.com
Tue Jan 25 11:58:54 EST 2005
A sticky issue has arisen with regard to the TARGET_ARCH/TARGET_OS CPP
symbols. I'd like to solicit feedback on the best course of action.
Sorry this is so long and the problem is so boring, but we ought to do
the right thing before 6.4.
Background
----------
Remember that in a GHC build:
- build refers to the platform we're building on
- host refers to the platform we're going to run GHC on
- target refers to the platform that this GHC build targets
Defines for foo_TARGET_ARCH, foo_TARGET_OS, and several other symbols,
are placed in ghc/includes/ghcconfig.h by the build system. Code in the
compiler (ghc/compiler) and the RTS (ghc/rts) gets hold of these symbols
by #including <ghcconfig.h>.
Also, we ship ghcconfig.h with GHC (in GHC 6.2 and earlier it was called
config.h), and lots of Haskell code includes it and tests
foo_TARGET_ARCH to do platform-conditional compilation.
Now, in GHC 6.4 we also automatically define the symbols foo_TARGET_OS
and foo_TARGET_ARCH without requiring the user to #include
<ghcconfig.h>. This seemed like a good idea at the time.
The Problem
-----------
When compiling the compiler itself, we get two foo_TARGET_ARCH symbols
defined: one by ghcconfig.h in the build tree, and one from the compiler
that is compiling GHC. If we're cross compiling, these will be
different. Previously, we got away with it because GHC didn't
automatically define foo_TARGET_ARCH.
Solutions:
(a) Rename the symbols that ghc defines automatically.
(b) Go back to not automatically defining these symbols.
(c) Rename TARGET_ARCH/TARGET_OS in ghcconfig.h.
Ramifications:
(a) Isn't really an option. It's too late to rename these
symbols, even though strictly speaking the "target"
isn't very meaningful outside a GHC build tree.
(b) Lots of code that says
#if __GLASGOW_HASKELL__ <= 602
#include <config.h>
#endif
has to change to
#if __GLASGOW_HASKELL__ <= 602
#include <config.h>
#else
#include <ghcconfig.h>
#endif
It's not too late to do this, but it's a bit painful.
(c) We could eg. rename "target" to "object". Or rename
TARGET_ARCH to target_arch (consistently). This would
have the advantage that the changes are confined to
the GHC source tree, but the difference would be
downright confusing.
I'm tending towards (b) as the least horrible thing to do. Any
thoughts?
Cheers,
Simon
More information about the Cvs-ghc
mailing list