| 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:dun...@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/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs