On 22/01/14 18:07, Rogan Creswick wrote:
Does the behavior change if you build with a sandbox? (without hiding either Cabal via ghc-pkg?)
Yes, in particular: $ ghc-pkg expose Cabal-1.18.1.2 $ rm -fr .cabal-sandbox cabal.sandbox.config dist $ cabal sandbox init $ cabal install --dependencies-only $ cabal install $ .cabal-sandbox/bin/ghc-imported-from src/Main.hs Main getArgs 11 11 --ghc-options --ghc-pkg-options runs with no problems. I dug into this a bit more and I think it's a bug in my own code: the error that I quoted before was not the executable blowing up, instead it was runGhc exploding because I did not pass the right flags to the GHC API when I called "load LoadAllTargets". Stepping back, I can reproduce the error with plain ghci: $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :l src/Main.hs [1 of 3] Compiling Language.Haskell.GhcImportedFrom.UtilsFromGhcMod ( Language/Haskell/GhcImportedFrom/UtilsFromGhcMod.hs, interpreted ) [2 of 3] Compiling Language.Haskell.GhcImportedFrom ( Language/Haskell/GhcImportedFrom.hs, interpreted ) Language/Haskell/GhcImportedFrom.hs:132:54: Couldn't match expected type `Distribution.PackageDescription.BuildInfo' with actual type `Cabal-1.16.0:Distribution.PackageDescription.BuildInfo' In the fourth argument of `getGHCOptions', namely `binfo' In a stmt of a 'do' block: getGHCOptions [] c (fromJust $ cradleCabalDir c) binfo In the expression: do { c <- findCradle; pkgDesc <- GhcMonad.liftIO $ parseCabalFile $ fromJust $ cradleCabalFile c; let binfo = head $ cabalAllBuildInfo pkgDesc; getGHCOptions [] c (fromJust $ cradleCabalDir c) binfo } Failed, modules loaded: Language.Haskell.GhcImportedFrom.UtilsFromGhcMod. whereas cabal repl works fine, because it parses the .cabal file and realises that it needs the earlier version of Cabal. Confirming this, if I use -package to specify the version of Cabal then it works fine: $ ghci -package Cabal-1.16.0 (all happy now) So I should look at how the latest Cabal (in particular "cabal repl") works out the right flags to pass to ghci, and incorporate that into my ghc-imported-from project. I see that the developer of ghc-mod has run into a similar issue recently: https://github.com/kazu-yamamoto/ghc-mod/issues/171
If I had to hazard a guess, I'd say that the inability to specify dependencies for the build process are causing this problem, even though you're using build-type: simple; one cabal is used to set cabal-specific details in the cabal_macros.h file (which I'm assuming you're using somewhere in the source?) and another is picked based on the build-depends.
That's just a guess, though... and if true, it's a wrinkle in the interactions between build-system dependencies and program build-time dependencies that I haven't run across before (even with Cabal-dev!).
Nope, it's a wrinkle in my understanding of Cabal/ghci/etc :) Thanks for the reply though, it helped me hunt down the problem. Cheers, -- Carlo Hamalainen http://carlo-hamalainen.net