[GHC] #10871: Implement "fat" interface files which can be directly compiled without source

GHC ghc-devs at haskell.org
Wed Oct 21 16:06:57 UTC 2015


#10871: Implement "fat" interface files which can be directly compiled without
source
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                Owner:  ezyang
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.11
      Resolution:                    |             Keywords:  backpack
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonmar):

 > We need a separate file format for Backpack.

 Well sure, I'm happy to move command-line flags into a file of some kind
 with sensible syntax.

 > It is GHC, not Cabal, who knows how to instantiate units.

 In my (perhaps naive) view of the way this works, "instantiating a unit"
 is just compiling modules in dependency order, exactly as GHC does today.
 This is the case that we already have covered; all of the new stuff is in
 typechecking modules without concrete dependencies.

 So yes - GHC instantiates units.  But installing the instantiated unit and
 recording it in the package database is Cabal's job.  The package database
 can record that we have an instance of A, and that it was built by
 instantiating A with B.

 > Cabal needs to ask GHC for information about how it instantiated units.

 I don't think so.  Why can't it look in the package database?


 On your point about shipping something usable in a timely manner, by all
 means forge ahead.  I don't want to block you, especially when you've done
 a lot more thinking about this problem and implementing it than I have!
 But I am very keen that we end up with a story that (a) retains the
 property of cabal-install depending only on its inputs, (b) keeps a
 sensible separation of layers between GHC, Cabal, and {cabal-
 install,stack}.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10871#comment:23>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list