ANYWAYS :)

the point is: there is a nonzero population of haskell folks who want to use ghc + cabal-install on a machine where they may not have admin / package manager powers, AND it requires some amount of cabal-install familiarity (or asking around) to find out about the ./boot-strap script that cabal comes with.  (I've definitely had 1-2 incidents where on a new server i did the bootstrap process by hand before i found out about that script)

at the very very least, the directions for boostrap cabal-install should be more discoverable


On Wed, Jan 22, 2014 at 10:45 AM, Johan Tibell <johan.tibell@gmail.com> wrote:
On Wed, Jan 22, 2014 at 12:57 AM, Herbert Valerio Riedel <hvr@gnu.org> wrote:
On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote:
> I feel this blurs the roles of GHC and the Platform.

IMO, that's a weak argument, as the roles are already blurred:

GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be
provided by the HP instead. Moreover, GHC ships with a set of base
libraries (which, and thus effectively GHC forces 20 or so packages
(fixed to specific package versions) into the HP and takes away
authority from the HP release process. But now the difficult to explain
thing is that GHC also bundles the library part of CABAL but
deliberately leaves out CABAL's frontend tool `cabal-install` only to
justify the existence of the HP a bit more? :-)

Cabal is part of GHC's build process and GHC uses data types from Cabal. That's why it's there. It's not because we want Cabal to be included (just like we don't want to ship those libs.) These are technical limitations.
 

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries