diff options
author | John Ericson <git@JohnEricson.me> | 2019-04-07 22:33:21 -0400 |
---|---|---|
committer | Marge Bot <ben+marge-bot@smart-cactus.org> | 2019-07-09 22:56:18 -0400 |
commit | 0472f0f6a92395d478e9644c0dbd12948518099f (patch) | |
tree | 811e61b4be392fbd68e7b3df24a82a6df74f89e5 /boot | |
parent | fb43bddc771094632bd08a4eab28fd3e714affd0 (diff) | |
download | haskell-0472f0f6a92395d478e9644c0dbd12948518099f.tar.gz |
Remove most uses of TARGET platform macros
These prevent multi-target builds. They were gotten rid of in 3 ways:
1. In the compiler itself, replacing `#if` with runtime `if`. In these
cases, we care about the target platform still, but the target platform
is dynamic so we must delay the elimination to run time.
2. In the compiler itself, replacing `TARGET` with `HOST`. There was
just one bit of this, in some code splitting strings representing lists
of paths. These paths are used by GHC itself, and not by the compiled
binary. (They are compiler lookup paths, rather than RPATHS or something
that does matter to the compiled binary, and thus would legitamentally
be target-sensative.) As such, the path-splitting method only depends on
where GHC runs and not where code it produces runs. This should have
been `HOST` all along.
3. Changing the RTS. The RTS doesn't care about the target platform,
full stop.
4. `includes/stg/HaskellMachRegs.h` This file is also included in the
genapply executable. This is tricky because the RTS's host platform
really is that utility's target platform. so that utility really really
isn't multi-target either. But at least it isn't an installed part of
GHC, but just a one-off tool when building the RTS. Lying with the
`HOST` to a one-off program (genapply) that isn't installed doesn't seem so bad.
It's certainly better than the other way around of lying to the RTS
though not to genapply. The RTS is more important, and it is installed,
*and* this header is installed as part of the RTS.
Diffstat (limited to 'boot')
0 files changed, 0 insertions, 0 deletions