JP Moresmau

Well yes that's one of the reasons I've abandonned BuildWrapper and EclipseFP. Since they rely on the GHC API, every new release of GHC mean having to adapt to the...

I've started using Leksah, since I'm not a huge emacs fan. It's OK but missing things I was used to in EclipseFP, hopefully it will improve if people use it...

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...

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...

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...

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

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...

The bug is on the EclipseFP side. We don't pass the preference path to Hoogle to scion-browser. However, we should look into /.eclipsefp/sandbox/bin, maybe copy your hoogle executable there as...

Hoogle may need other files than just the binary. Hopefully the issue will be fixed in the next release of EclipseFP, it's a regression (the code that passes the path...

As the message explicitly says, this is a GHC bug. EclipseFP does a lot more than just building, so buildwrapper uses the GHC API.