Can't install packages with my inplace compiler
Simon Peyton Jones
simonpj at microsoft.com
Wed Nov 5 09:50:26 UTC 2014
| Actually I'd suggest you use the Cabal and cabal-install that are part
| of the ghc source tree, rather than Cabal/cabal-install HEAD. The two
| are not always the same.
Aha ok, thank you. How exactly do I do that? Where is the executable cabal-install in the tree? IN inplace/bin I see an executable ghc-cabal. Is that it?
Alternatively, "Plan B" on https://ghc.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace
(which I confess I'd forgotten about) describes a different plan that doesn't mention cabal-install at all. Is that better?
Thanks
Simon
| -----Original Message-----
| From: Duncan Coutts [mailto:duncan at well-typed.com]
| Sent: 05 November 2014 09:41
| To: Simon Peyton Jones
| Cc: Edward Z. Yang; Herbert Valerio Riedel; GHC Devs
| Subject: Re: Can't install packages with my inplace compiler
|
| On Tue, 2014-11-04 at 21:04 +0000, Simon Peyton Jones wrote:
| > | Yeah, that's too old; and there's not been a release of a Cabal
| > | which is new enough to do what you want.
| >
| > Wow! I'm doing the most basic thing: using Cabal to install a
| package with a specified GHC.
| >
| > I'll try what you suggest.
|
| Actually I'd suggest you use the Cabal and cabal-install that are part
| of the ghc source tree, rather than Cabal/cabal-install HEAD. The two
| are not always the same.
|
| We try to avoid getting into situations where older cabal binaries
| cannot use the current ghc, but it does happen sometimes when we make
| changes in ghc that are not fully backwards compatible. In this case
| we (or rather I) removed ghc's support for single-file style package
| dbs and we later discovered that Cabal was in one place still using
| that style. It's plausible that we might want to add back some hack to
| ghc-pkg to allow older Cabal versions to work with ghc head.
|
| So in this situation we have to use the Cabal library (that you built
| with ghc head), to build cabal-install and its dependencies in the old
| style, using Setup.hs. That'll also need the dev version of zlib, due
| to the AMP things.
|
| > Duncan: would a release be a good plan?
|
| We tend not to make intermediate releases to support ghc head because
| when we're making changes to work with ghc head we're not always in a
| good spot to make releases for the general public (we tend to be in
| the middle of things and not have enough testing feedback). Also,
| people using ghc head already have the corresponding version of
| Cabal/cabal-install in their source tree which they can install and
| use.
|
| On the other hand, when we think we're in a reasonable state with
| Cabal testing, and ghc is getting into release mode and we have more
| people needing to test ghc head, then of course making a release
| becomes important.
|
| My point is that when Edward and I were making all these breaking
| changes to Cabal/ghc in the packaging area is exactly the wrong time
| to make a cabal release. In this situation we just have to tell ghc
| hackers to use the Cabal/cabal-install from the ghc tree.
|
| --
| Duncan Coutts, Haskell Consultant
| Well-Typed LLP, http://www.well-typed.com/
More information about the ghc-devs
mailing list