Open joeyh opened 8 years ago
Seems like the explicit-setup-deps have somehow gotten applied to building dependencies of my package, and not only to the package itself.
The issue here is that we are directly invoking ghc
to build Setup.hs. This usually works fine with default settings and using whatever packages are installed. explicit-setup-deps
locks down the dependencies used, but does not pass any additional flags to ghc
. We should probably re-use our stack ghci
code, which determines the ghc flags to use to build a package, and when explicit-setup-deps
is on, and pass those arguments.
It seems a little weird to use all the library settings for building the Setup.hs, but that seems like the most reasonable thing to do. I'm not sure how the new cabal custom-setup stuff works, but perhaps it treats the Setup.hs as another component. In that case, we could do something far more principled for this.
The new cabal custom-setup seems the way to go. I have added a setup-depends field for my package with the setup's dependencies, and if stack gets support for that I shouldn't need to worry about explicit-setup-deps, I hope.
git-annex's Setup.hs needs some of its dependencies to be installed, so I added this to its stack.yaml on a user's request:
But this made stack build fail, in a strange way:
This build failure occurred using stack 1.0.4.3 on Debian 8.3 stable. ghc and some haskell libraries are installed system-wide using apt. (So, the build succeeds when explicit-setup-deps is not enabled; Setup is built using the system-wide installed libs.) System is otherwise stock.
The libtinfo5 package is installed (it's a standard part of Debian), but the -dev package is not, so linking with -ltinfo won't work. I was able to work around the build failure by installing libtinfo-dev.
Full build output with --verbosity debug --cabal verbose attached below.