RFC: include a cabal-install executable in future GHC releases
carter.schonwald at gmail.com
Wed Jan 22 16:18:08 UTC 2014
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
at the very very least, the directions for boostrap cabal-install should be
On Wed, Jan 22, 2014 at 10:45 AM, Johan Tibell <johan.tibell at gmail.com>wrote:
> On Wed, Jan 22, 2014 at 12:57 AM, Herbert Valerio Riedel <hvr at 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 at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries