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.tib...@gmail.com>wrote: > On Wed, Jan 22, 2014 at 12:57 AM, Herbert Valerio Riedel <h...@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 > librar...@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
