Removing GHC's dependency on Cabal
Yuri de Wit
ydewit at gmail.com
Thu Jul 24 15:32:43 UTC 2014
On Thu, Jul 24, 2014 at 11:59 AM, Brandon Allbery <allbery.b at gmail.com>
> On Thu, Jul 24, 2014 at 10:55 AM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>> To me it seems simple and obvious! Why are we going round the houses to
>> do something so simple?
> So cabal can maintain its conceit that it supports more than just ghc.
I don't understand this as an argument against the ghc-db library, which to
me also seems the simple and obvious solution.
Having a ghc-db library will mean one of two options:
1. The *ghc-db* is GHC-specific and will be used by the GHC specific
wrappers in Cabal: doesn't cabal already deals with each compiler
2. The ghc-db is really *hs-db* and a library contract that can be reused
by all haskell compilers (i.e. part of The Haskell Cabal)
In both cases, the assumption is that ghc-db/hs-db should have a stable API.
Now, choosing option (1) doesn't eliminate option (2). When and if there is
a broad agreement across all compilers, ghc-db could become hs-db and be
incorporate into The Haskell Cabal.
> brandon s allbery kf8nh sine nomine
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> cabal-devel mailing list
> cabal-devel at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cabal-devel