On Thu, 2013-03-14 at 16:44 +0000, Simon Peyton-Jones wrote:

Yes I think that'd be a great plan. It's bizarre that GHC depends on *all* of Cabal, but only uses a tiny part of it (more or less the Package data type I think).

The sensible way to split it (I think) would be like this: cabal-lib: Distribution.* -- containing definitions of types and parsers & pretty printers -- including the InstalledPackageInfo cabal-build-simple Distribution.Simple.* -- the build system for "Simple" packages cabal -- the program, what is currently called cabal-install And then the ghc package would only depend on the cabal-lib package. But it's that package that is going to use bytestring, text, parsec etc, for its type definitions and parser. The InstalledPackageInfo and its parser is what ghc and ghc-pkg primarily use (though there's the opportunity to share code for handling package indexes) and that type and that parser are also going to end up using text and parsec etc. It'd be possible to split things out further and have InstalledPackageInfo and the types it uses and a special parser just for that with fewer dependencies, but I'm not sure that's really worth it and it would duplicate things (the types and/or parsers shared by InstalledPackageInfo and the source package description). So all in all, the split I suggest above makes sense for its own reasons but it wouldn't help ghc here, and a further split just to help ghc would be rather annoying. Duncan

| -----Original Message----- | From: cabal-devel-bounces@haskell.org [mailto:cabal-devel-bounces@haskell.org] | On Behalf Of Administrator | Sent: 14 March 2013 15:23 | To: Duncan Coutts | Cc: Lentczner; cabal-devel; Haskell Libraries; ghc-devs@haskell.org | Subject: Re: Advance notice that I'd like to make Cabal depend on parsec | | 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. | | 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. | | 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). | | | On Thu, Mar 14, 2013 at 12:12 PM, Duncan Coutts | wrote: | > On Thu, 2013-03-14 at 16:06 +0100, Gregory Collins wrote: | >> On Thu, Mar 14, 2013 at 3:53 PM, Duncan Coutts | > > wrote: | >> | >> > Hi folks, | >> > | >> > I want to give you advance notice that I would like to make Cabal depend | >> > on parsec. The implication is that GHC would therefore depend on parsec | >> > and thus it would become a core package, rather than just a HP package. | >> > So this would affect both GHC and the HP, though I hope not too much. | >> | >> | >> +1 from me, although the amount of potential knock-on work might be | >> discouraging. The current cabal-install bootstrap process (which is | >> currently pretty easy and is necessary at times) will get a bunch more deps | >> as a result of this change, no? | > | > Yes it will, but given that we do have a script it's not too bad I | > think. And overall I think its worth it to have the better error | > messages, performance and memory use. Do you have any idea how slow it | > is to parse all the .cabal files on hackage, and how much memory that | > takes? You'd be horrified :-) | > | > Duncan | > | > | > _______________________________________________ | > cabal-devel mailing list | > cabal-devel@haskell.org | > http://www.haskell.org/mailman/listinfo/cabal-devel | | _______________________________________________ | cabal-devel mailing list | cabal-devel@haskell.org | http://www.haskell.org/mailman/listinfo/cabal-devel