• Simon Marlow's avatar
    Rationalise GhcMode, HscTarget and GhcLink · 3c22606b
    Simon Marlow authored
    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.