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).
Simon | -----Original Message----- | From: cabal-devel-boun...@haskell.org [mailto:cabal-devel-boun...@haskell.org] | On Behalf Of Administrator | Sent: 14 March 2013 15:23 | To: Duncan Coutts | Cc: Lentczner; cabal-devel; Haskell Libraries; ghc-d...@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 | <duncan.cou...@googlemail.com> wrote: | > On Thu, 2013-03-14 at 16:06 +0100, Gregory Collins wrote: | >> On Thu, Mar 14, 2013 at 3:53 PM, Duncan Coutts | <duncan.cou...@googlemail.com | >> > 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 _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
