Can't install packages with my inplace compiler

[Simon Peyton Jones]

|  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/