Rationalise GhcMode, HscTarget and GhcLink
This patch cleans up the GHC API, and adds some functionality: we can
now compile to object code inside GHCi.
Previously we had:
data GhcMode
= BatchCompile
| Interactive
| OneShot
| JustTypecheck
| MkDepend
data HscTarget
= HscC
| HscAsm
| HscJava
| HscInterpreted
| HscNothing
There was redundancy here; if GhcMode is Interactive, then only
HscInterpreted makes sense, and JustTypecheck required HscNothing.
Now we have:
data GhcMode
= CompManager -- ^ --make, GHCi, etc.
| OneShot -- ^ ghc -c Foo.hs
| MkDepend -- ^ ghc -M, see Finder for why we need this
and HscTarget remains as before.
Previously GhcLink looked like this:
data GhcLink = NoLink | StaticLink
Now we have:
data GhcLink = NoLink | LinkBinary | LinkInMemory
The idea being that you can have an HscTarget of HscAsm (for example)
and still link in memory.
There are two new flags:
-fobject-code selects object code as the target (selects
either -fasm or -fvia-C, whichever is the default)
This can be usd with ':set' in GHCi, or on the command line.
-fbyte-code sets byte-code as the target. Only works in GHCi.
One day maybe this could save the byte code in a file
when used outside GHCi.
(names chosen for consistency with -fno-code).
Changes to the GHC API: newSession no longer takes the GhcMode
argument. The GhcMode defaults to CompManager, which is usually what
you want. To do JustTypecheck now, just set hscTarget to HscNothing.
12 files changed: