RFC: include a cabal-install executable in future GHC releases
roma at ro-che.info
Wed Jan 22 12:22:41 UTC 2014
* Herbert Valerio Riedel <hvr at gnu.org> [2014-01-22 12:55:53+0100]
> On 2014-01-22 at 10:08:02 +0100, Henning Thielemann wrote:
> > Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel:
> >> 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.
> > At least haddock is bound to the specific GHC version.
> When I look at http://hackage.haskell.org/package/haddock, there are
> multiple versions, 2.12.0 and the 4 versions of 2.13.*, which are all
> declared to work with ghc == 7.6.*, that is, 5 haddock versions
> compatible with 3 released versions of GHC 7.6. So while it may be bound
> to a major version of the GHC API, haddock can obviously have more
> releases than GHC has releases (otherwise it could just carry GHC's
> version), and can therefore be updated.
Henning could be more specific in his claim that "haddock is bound to
the specific GHC version".
I guess he's referring to the binary rather than source distribution's
compatibility. Assuming static linking w.r.t. the ghc package, the
incompatibility with a different GHC version could still arise from the
fact that haddock (as any other GHC API using application, I suppose)
makes use of the GHC's lib directory, although I don't know the details.
If we are talking about installing haddock from source (using
cabal-install), then it should be no different from installing, say,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the Libraries