Removing GHC's dependency on Cabal
Simon Peyton Jones
simonpj at microsoft.com
Thu Jul 24 14:55:03 UTC 2014
The way I am thinking of it is this. In "Simon's proposal" in
the ghc-db library is simply a Haskell library that gives a programmatic way to interact with GHC's installed package database(s). GHC needs that. ghc-pkg needs that. cabal needs that. There should be one thing that supplies it.
Cabal currently shells out to ghc-pkg, which in turn mandates a special file format (the .conf file) that Cabal uses to communicate its wishes to ghc-pkg. This needs syntax, a parser, a pretty printer, and is, to all intents and purposes just as stable, or unstable, as a Haskell API to ghc-db would be.
To me it seems simple and obvious! Why are we going round the houses to do something so simple?
| -----Original Message-----
| From: cabal-devel [mailto:cabal-devel-bounces at haskell.org] On Behalf Of
| Joachim Breitner
| Sent: 24 July 2014 15:07
| To: ghc-devs at haskell.org
| Cc: cabal-devel
| Subject: Re: Removing GHC's dependency on Cabal
| Am Donnerstag, den 24.07.2014, 14:56 +0100 schrieb Edward Z.Yang:
| > We were wondering if there was any reason to prefer the former
| > situation over the latter.
| One way to decide that is to ask “What is the more stable interface”?
| I.e. under what circumstances will upgrading Cabal require upgrading
| packages depended upon by ghc.
| So while Duncan’s Proposal has no such dependency, in Simon’s proposal
| there is one. Will ghc-db’s interface be stable enough that the Cabal
| developers will be happy to build against a very old version of it?
| Joachim “nomeata” Breitner
| mail at joachim-breitner.de • http://www.joachim-breitner.de/
| Jabber: nomeata at joachim-breitner.de • GPG-Key: 0xF0FBF51F
| Debian Developer: nomeata at debian.org
More information about the cabal-devel