Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem version cabal library #18

Open
aalex10 opened this issue Oct 20, 2013 · 11 comments
Open

Problem version cabal library #18

aalex10 opened this issue Oct 20, 2013 · 11 comments

Comments

@aalex10
Copy link

aalex10 commented Oct 20, 2013

Helllo, I have a problem with buildwrapper

$ cabal --version
cabal-install version 1.18.0.2
using version 1.18.1 of the Cabal library

$ cabal-dev --version
cabal-dev 0.9.2
built with Cabal 1.16.0

$ buildwrapper --version
buildwrapper executable, version 0.7.6
using version 1.16.0 of the Cabal library

Log Eclipse:
!ENTRY net.sf.eclipsefp.haskell.ui 4 0 2013-10-20 23:51:21.906
!MESSAGE The version of the Cabal library used to build the cabal executable, 1.18.1.1, does not match the version of the Cabal library used to build the buildwrapper executable, 1.16.0. Please rebuild buildwrapper with the cabal executable /Users/XXX/.cabal/bin/cabal.

I'm use:
mac - 10.8.5
haskell-plataform - latest version
Eclipse and EclipseFP - Iatest version

@JPMoresmau
Copy link
Owner

Have a look at the FAQ (http://eclipsefp.github.io/faq.html). BuildWrapper depends on the GHC library, which depends on the Cabal library, so unless you've rebuilt your GHC from source, GHC still uses the 1.16 version of the library, and hence BuildWrapper does too. You cannot use a more recent version of Cabal that what GHC has been built with, basically. There is talk about removing the dependency between GHC and Cabal soon.

@miguel-negrao
Copy link

Perhaps it would be good to explicitely say in the installation instructions which combinations of ghc/cabal-install are allowed:

  • ghc 7.6.x -> Cabal 1.16.0 -> cabal-install 1.16.0.x
  • ghc 7.8.x -> Cabal 1.18.1.3 -> cabal-install 1.18.0.x

@JPMoresmau
Copy link
Owner

Well, it's more complicated than that. You now should be able to use a different version of cabal than what your GHC came with, because we now use dynamic-cabal. For example I now use GHC 7.8 with Cabal 1.20 and everything works.

@miguel-negrao
Copy link

So what is in the faq is no longer true ?

"Buildwrapper depends on both the GHC API and the Cabal API, and then calls cabal-install too. Usually the GHC API has a dependency on the Cabal API too, so if you install a new version of both the Cabal library and the cabal-install tool, Buildwrapper may not use them because the dependency on GHC will force it to use the older Cabal library!
In this instances, dropping to a shell and using cabal with the verbose flag usually helps. The key message here is "don't panic". You may need to go back to the older instance of cabal (the one GHC uses) or reinstall GHC itself."

If so, it should be updated.

Is that also true for ghc 7.6.3 ?

@miguel-negrao
Copy link

Using ghc 7.6.3, buildwrapper (executable, version 0.8.6 using version 1.16.0 of the Cabal library) and cabal 1.20.0.1 doesn't seem to work:

buildwrapper: Left over temporary directory not removed: /tmp/dynamic-cabal.11
<command line>: cannot satisfy -package Cabal-1.20.0.1
    (use -v for more information)

Was this supposed to work ?

@JPMoresmau
Copy link
Owner

This is dynamic-cabal. When running it tries to use the current version of Cabal, but doesn't find it, for some reason. Make sure all your PATH are correct in EclipseFP and the script that launches it, etc.

@miguel-negrao
Copy link

The path is correct in eclipse.

cabal info Cabal
* Cabal            (library)
    Synopsis:      A framework for packaging Haskell software
    Versions available: 1.14.0, 1.16.0.2, 1.16.0.3, 1.18.0, 1.18.1.1, 1.18.1.2,
                        1.18.1.3, 1.20.0.0, 1.20.0.1 (and 21 others)
    Versions installed: 1.16.0

Should I have version 1.20.0.1 installed instead of 1.16.0 of the Cabal library ?

@JPMoresmau
Copy link
Owner

Well dynamic-cabal searchs for Cabal 1.20, which means you've build buildwrapper with Cabal 1.20...

@miguel-negrao
Copy link

Yes, I've built buildwrapper with cabal-install 1.20.0.2, but when I installed cabal-install 1.20.0.2 (via cabal install cabal-install) it didn't change the version of the Cabal library installed, it's still the 1.16 that came with the haskell platform. So... should I add Cabal 1.20.0.1 library to the dependencies of my project, should I update the version of the Cabal library installed for my user, or... ?

@JPMoresmau
Copy link
Owner

You should not modify your project for the requirements of the build tool, no. I know these things are a mess, and while sandboxing helps in some cases, it provides an additional level of complexity. Basically you've built buildwrapper with Cabal 1.20, so it has that version referenced in the code and dynamic-cabal requires that version when running. You could install Cabal 1.20 in your system package database (--global), or in the sandbox where EclipseFP installs its tools (/eclipsefp/.metadata/.plugins/net.sf.eclipsefp.haskell.ui/sandbox/.cabal-sandbox). But now I'm confused, what Cabal does EclipseFP uses? Or just reinstall buildwrapper with Cabal 1.16 if you don't care about Cabal 1.20.

@miguel-negrao
Copy link

Installing Cabal 1.20.0.1 library for my user account solved it (cabal install Cabal) , eclipsefp is now working correctly. Eclipsefp is using the cabal-install 1.20.0.2 installed via 'cabal install cabal-install' which is at ~/.cabal/bin .

Btw, eclipsefp is crashing every couple of minutes...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants