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