Skip to content
  • 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