[GHC] #8244: Removing the Cabal dependency

GHC ghc-devs at haskell.org
Thu Aug 28 13:19:16 UTC 2014


#8244: Removing the Cabal dependency
-------------------------------------+-------------------------------------
              Reporter:  nh2         |            Owner:  duncan
                  Type:  bug         |           Status:  new
              Priority:  normal      |        Milestone:
             Component:  Compiler    |          Version:  7.6.3
            Resolution:              |         Keywords:
      Operating System:              |     Architecture:  Unknown/Multiple
  Unknown/Multiple                   |       Difficulty:  Unknown
       Type of failure:              |       Blocked By:
  None/Unknown                       |  Related Tickets:
             Test Case:              |
              Blocking:              |
Differential Revisions:  D172        |
-------------------------------------+-------------------------------------

Comment (by duncan):

 ezyang and I discussed this on IRC, but for the record...

 Replying to [comment:26 ezyang]:
 > duncan: I also realized I had another major design question about the
 new binary package format. In your design doc, you state that the reason
 we need to store Cabal's information in the binary package database is
 because ghc-pkg needs to be able to regurgitate the information later.
 However, isn't the textual files in the database intended to be the
 "primary" representation, in which case can't ghc-pkg just hit the actual
 filesystem rather than using the binary package database?

 It could read the text files, but this would be slower than using the
 binary cache. The performance of ghc-pkg dump is actually important. It's
 used by cabal to get the installed packages.

 > Normally, I'd be indifferent, but if we can reduce the size of the
 binary package database that will improve GHC startup times. And it's not
 like we need to make sure ghc-pkg's 'describe' functionality is blazingly
 fast...

 The binary file is structured so that the part that ghc reads comes first.
 So the extra data for ghc-pkg to read back will not affect the time taken
 to read the part for ghc.

 ghc-pkg describe does not need to be fast, but ghc-pkg dump does (at least
 reasonably so).

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


More information about the ghc-tickets mailing list