build using cabal sandbox on ghc-8.0.1 #32
Conversation
|
@vu3rdd Well done. I like the idea of using a cabal freeze file to specify a set of versions that work together. My only minor gripe is that this cabal freeze file contains many packages (like all of yesod*) that are neither needed or used by haskell-tor. Would it be possible to edit the freeze file to drop all packages haskell-tor doesn't depend on explicitly? I also wonder if it would be possible (and make sense) to have different versions of the freeze file for different ghc versions. |
|
@erikd Thanks. Great feeling when one gets a pat from an experienced Haskeller. The cabal.config file I started with was from a stackage nightly snapshot from two days ago. I then did a cabal freeze to create the one I checked in. It might be possible to drop the packages not needed by haskell-tor. and its transitive dependencies I will take a look. I am not sure about the freeze files for different ghc versions. Stackage lts releases target specific ghc versions. It could be possible with some shell/symlink tricks to switch cabal.config, I think. But I don't know the cabal way of switching the config file. I will try to dig into it as well. |
|
(/cc @erikd) I am having problems building it on OSX, so even with cabal.config it is not a reproducible build. :( Building with a |
|
@erikd The cabal.config file looks clean (see the second commit in this PR). The |
|
I'm pretty sure this: is due to some incompatibility between |
|
Thanks @erikd. That worked perfectly. |
|
Hmmm. This is looking like it's failing all over Travis. Any idea what's going on? |
|
@acw I made an attempt to fix the travis failures. Still a wip in the branch https://github.com/vu3rdd/haskell-tor/tree/fix-travis-for-ghc-8.0.1. With that, GHC 7.8.4 based build fails to build hans. The library itself builds, but the web-server executable has an ambiguous import. 7.10.3 and 8.0.1 are successfully built but the testsuite fails with one failure. Here are the results: https://travis-ci.org/vu3rdd/haskell-tor/builds/153913806 |
|
The cabal.config fine cannot have tight dependencies on base if you want it to compile with more than one version of ghc. GHC 8.0 ships with base-4.9, GHC 7.10 with base-4.8 and so on. For dependency constaint foe |
|
I relaxed the dependency in the cabal.config of base to |
|
I changed it as per your suggestion. Thanks @erikd. |
|
I'm pretty sure some of the other packages that are tightly tied to GHC will also be an issue. For example; |
|
I did a travis build of my branch. The logs are here. GHC 7.8.xThis fails with this following error: GHC 7.10.x and GHC 8.0.1Fails in the |
|
Got it. The test-suite error can be fixed by something in one of my branches (testing, which is waiting for an upstream TLS release). You can either do some fancy pulling and cherry picking, or you can just copy this change: 6e37c44 ... or just tell me you're tired of this, and I'll accept the merge and continue to wait for my upstream TLS change to fix the build problem. |
|
@acw Where are your upstream TLS changes? I don't see a PR at https://github.com/vincenthz/hs-tls/ for that. |
|
@erikd It's this one: It's been merged, but an updated version hasn't been pushed to Hackage, yet. |
|
Ah right. Thanks @acw ! |
|
@vu3rdd You should probably rebase against master. The build output has come compilier warnings that I have already fixed. |
|
@erikd hmm, it seem already on top of the latest master which has some of your commits on compiler warnings merged in. I am wondering if I managed to introduced some new warnings here. |
I could build with the cabal.config from a stackage snapshot and ghc-8.0.1 and the small attached patch and also run the test suite with one failure. I removed the version pinning in the .cabal file and instead let cabal.config (output of
cabal freeze) do the dependency resolution. Not sure if this is acceptable. Please have a look. Thanks.