[GHC] #8244: Removing the Cabal dependency
GHC
ghc-devs at haskell.org
Fri Sep 6 17:17:10 CEST 2013
#8244: Removing the Cabal dependency
------------------------------------+-------------------------------------
Reporter: nh2 | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.6.3
Keywords: | Operating System: Unknown/Multiple
Architecture: Unknown/Multiple | Type of failure: None/Unknown
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
------------------------------------+-------------------------------------
GHC depends on cabal, which is so far has been problematic many times, for
many reasons.
A few discussions include:
* http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html
* http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html
GHC uses only a very small part of Cabal, in these files:
{{{
./compiler/ghci/Linker.lhs
./compiler/main/Packages.lhs
./compiler/main/PackageConfig.hs
./compiler/main/Finder.lhs
}}}
plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs (see
http://www.haskell.org/pipermail/haskell-cafe/2013-September/108750.html
for details).
It was proposed that either
* the package format could be a plain specification without direct code
dependencies
* the Cabal package could be split off into Cabal-the-build-system and a
minimal part to describe the package DB to be shared by Cabal and GHC
The Cabal part that is used is in only a few modules of Distribution.*
while the remaining majority of the Cabal-the-library package is not used
(e.g. none of Distribution.Simple.*).
Decoupling GHC and Cabal seems to be a public desire, yet there are some
problems with these approaches. Let us discuss them in this ticket.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8244>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list