Advance notice that I'd like to make Cabal depend on parsec

[Duncan Coutts]

On Thu, 2013-03-14 at 12:22 -0300, Administrator wrote:
> This GHC dependency on Cabal is putting a rather troubling constraint
> in Cabal's evolution, which in my opinion is a serious problem. When I
> first took a look at the dependencies between GHC and Cabal I found it
> a bit strange that GHC would depend on Cabal as I would expect GHC to
> be as low in the dependency tree as possible to avoid exactly these
> kinds of problems.

The problem is that a compiler is a rather sophisticated application and
so though you'd like it to have minimal deps, it needs to do so much
stuff that it ends up needing lots of deps to support its features.

Things would be easier if that were not the case, and it's made harder
by the fact that ghc is not just a program, but it's exposed as a
library, which exposes all of its dependencies.

> These GHC dependencies on Cabal are in fact small (see
> http://hackage.haskell.org/trac/ghc/attachment/ticket/7740/ghc-2.png
> for a summary) and with a little bit of refactoring it would be
> possible to split these dependencies into a very small shared package
> with minimal or no further dependencies. This would liberate Cabal to
> make the necessary refactoring.

Except that the bits of Cabal that ghc needs are exactly the bits that
will now need parsec, text etc. The shared part would be the part that
defines the InstalledPackageInfo and the parser for that.

Also, though the ghc library has only relatively small dependencies on
Cabal, the ghc build process uses Cabal extensively, and currently the
system is that libraries that ghc needs to build get included as core
libraries and shipped with ghc. That itself could change but it's also
more work.

> IMHO, the addition of these new dependencies to Cabal should go
> together with splitting the GHC-Cabal shared dependencies into a
> separate package so that there would be no additional coordination
> needed from then on between these two development efforts (except when
> dealing with this new package).

So I would consider this if I thought it'd make a difference. In
particular at some point we'll want to split the Cabal lib into the bit
that just defines types and parsers etc, and the part that is a build
system. But even that wouldn't save us any dependencies in this
situation.

Duncan