#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?
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
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. 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