[Haskell-cafe] Cabal version constraint seems to be ignored.

[Carlo Hamalainen]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140122/20c06845/attachment.html>