[Haskell-cafe] GHC API + Cabal API + Cabal version checks: is there a way out?

[Roman Cheplyaka]

The right solution for Cabal would be not to know anything about the
GHC's database format at all.

GHC and cabal communicate via a command line interface (`ghc-pkg dump`
in our direction; `ghc-pkg update` in the other). So it would suffice to
have a library which implements parsing and printing of the package
description, and have that library shared between GHC and Cabal.

(Which I think is more or less what you guys are suggesting, only I'd
like to point out that we should be focusing on the protocol instead of
the database format. The latter should be opaque.)

Roman

* Niklas Hambüchen <mail at nh2.me> [2013-09-06 22:42:28+0900]
> On Fri 06 Sep 2013 22:13:58 JST, Yuri de Wit wrote:
> > The right solution, imho, is to review these dependencies and move
> > the low level ones out into a separate package that is shared by both
> > ghc and cabal and that will rarely change. The direct side effect of
> > this is that ghc would not be tied directly to a specific cabal
> > version and you would not have to deal with this issue.
> 
> This sounds very right to me.
> 
> There should be something that describes what a GHC package database 
> is, as minimally as possible (perhaps even only the data types).
> 
> In the end, ghc is the defining side here - cabal is only a tool that 
> builds on top of these definitions.
> 
> Then ghc could finally be decoupled from Cabal.
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130906/c7945546/attachment.pgp>