Skip to content
Snippets Groups Projects
Commit 0472f0f6 authored by John Ericson's avatar John Ericson Committed by Marge Bot
Browse files

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.
parent fb43bddc
No related merge requests found
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment