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
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe