• 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.
    3c22606b
MkIface.lhs 49.3 KB