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.
Showing with 283 additions and 163 deletions