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.