
Gabriel Gonzalez has gotten Cabal benchmark integration working for containers, and then I broke it without realizing I'd done so because Travis CI wasn't building the benchmarks. When I got them working again locally and tried enabling them in .travis.yml (just adding --enable-benchmarks to the cabal configure line), things went kablooey: https://travis-ci.org/haskell/containers/jobs/156997144 Does anyone know how to interpret those entrails? Is this something that can be fixed?

Hello David, I can take a closer work, but here's how you can debug it yourself: 1. Repro it on not-Travis (given that it's a solver error, should be easy) 2. Turn on -v 3. Look through the entrails to see why criterion is not satisfiable. Maybe even just look at the dependencies in the benchmarks section. Could it be a cyclic dependency problem? Edward Excerpts from David Feuer's message of 2016-09-02 01:04:33 -0400:
Gabriel Gonzalez has gotten Cabal benchmark integration working for containers, and then I broke it without realizing I'd done so because Travis CI wasn't building the benchmarks. When I got them working again locally and tried enabling them in .travis.yml (just adding --enable-benchmarks to the cabal configure line), things went kablooey: https://travis-ci.org/haskell/containers/jobs/156997144
Does anyone know how to interpret those entrails? Is this something that can be fixed?

David Feuer
Gabriel Gonzalez has gotten Cabal benchmark integration working for containers, and then I broke it without realizing I'd done so because Travis CI wasn't building the benchmarks. When I got them working again locally and tried enabling them in .travis.yml (just adding --enable-benchmarks to the cabal configure line), things went kablooey: https://travis-ci.org/haskell/containers/jobs/156997144
Does anyone know how to interpret those entrails? Is this something that can be fixed?
I think you just need to add --enable-tests and --enable-benchmarks to "cabal install --only-dependencies". Then you should also be able to remove the manual install of test-framework and friends. Cheers Moritz

Hi,
On 2 September 2016 at 06:04, David Feuer
Does anyone know how to interpret those entrails? Is this something that can be fixed?
I think you just need to install the benchmark suite deps manually, like you do for the test suite: https://github.com/haskell/containers/blob/master/.travis.yml#L31 Then you should be able to do 'configure --enable-benchmarks'. The problem is that criterion itself depends on containers, and the solver can't handle such circular deps currently: https://github.com/haskell/cabal/issues/1575

Thanks a lot. I think that's it.
On Sep 2, 2016 7:36 AM, "Mikhail Glushenkov"
Hi,
On 2 September 2016 at 06:04, David Feuer
wrote: Does anyone know how to interpret those entrails? Is this something that can be fixed?
I think you just need to install the benchmark suite deps manually, like you do for the test suite:
https://github.com/haskell/containers/blob/master/.travis.yml#L31
Then you should be able to do 'configure --enable-benchmarks'.
The problem is that criterion itself depends on containers, and the solver can't handle such circular deps currently:

Indeed, that fixed the problem. Unfortunately, now I have a different
problem. The CI build with benchmarks takes *much* longer than the one
without (I think this is mostly because of the time required to
install Criterion's dependencies). Is there some way to make Travis
build benchmarks for just one GHC version, and let the rest build just
the library and tests?
On Fri, Sep 2, 2016 at 10:52 AM, David Feuer
Thanks a lot. I think that's it.
On Sep 2, 2016 7:36 AM, "Mikhail Glushenkov"
wrote: Hi,
On 2 September 2016 at 06:04, David Feuer
wrote: Does anyone know how to interpret those entrails? Is this something that can be fixed?
I think you just need to install the benchmark suite deps manually, like you do for the test suite:
https://github.com/haskell/containers/blob/master/.travis.yml#L31
Then you should be able to do 'configure --enable-benchmarks'.
The problem is that criterion itself depends on containers, and the solver can't handle such circular deps currently:

Hi,
On 2 September 2016 at 16:55, David Feuer
Indeed, that fixed the problem. Unfortunately, now I have a different problem. The CI build with benchmarks takes *much* longer than the one without (I think this is mostly because of the time required to install Criterion's dependencies).
Try enabling caching on Travis: https://docs.travis-ci.com/user/caching/#Arbitrary-directories https://github.com/haskell/cabal/blob/master/.travis.yml#L86

Last I spoke to Herbert, he didn't think the caching stuff was likely
to be feasible for containers, because of its unusual place in the
ecosystem. There may be some way around it though.
On Fri, Sep 2, 2016 at 11:57 AM, Mikhail Glushenkov
Hi,
On 2 September 2016 at 16:55, David Feuer
wrote: Indeed, that fixed the problem. Unfortunately, now I have a different problem. The CI build with benchmarks takes *much* longer than the one without (I think this is mostly because of the time required to install Criterion's dependencies).
Try enabling caching on Travis:
https://docs.travis-ci.com/user/caching/#Arbitrary-directories https://github.com/haskell/cabal/blob/master/.travis.yml#L86

The way that Cabal's CI does it is that it uses new-build, and places .cabal/store and some related directories in the cache. Here's the snippet: cache: directories: - $HOME/.cabal/packages - $HOME/.cabal/store - $HOME/.cabal/bin # We remove the index because it churns quite a bit and we don't want # to pay the cost of repeatedly caching it even though we don't care # about most changing packages. before_cache: - rm -fv $HOME/.cabal/packages/hackage.haskell.org/build-reports.log - rm -fv $HOME/.cabal/packages/hackage.haskell.org/00-index* Full yaml: https://github.com/haskell/cabal/blob/master/.travis.yml Edward Excerpts from David Feuer's message of 2016-09-02 12:04:40 -0400:
Last I spoke to Herbert, he didn't think the caching stuff was likely to be feasible for containers, because of its unusual place in the ecosystem. There may be some way around it though.
On Fri, Sep 2, 2016 at 11:57 AM, Mikhail Glushenkov
wrote: Hi,
On 2 September 2016 at 16:55, David Feuer
wrote: Indeed, that fixed the problem. Unfortunately, now I have a different problem. The CI build with benchmarks takes *much* longer than the one without (I think this is mostly because of the time required to install Criterion's dependencies).
Try enabling caching on Travis:
https://docs.travis-ci.com/user/caching/#Arbitrary-directories https://github.com/haskell/cabal/blob/master/.travis.yml#L86
participants (4)
-
David Feuer
-
Edward Z. Yang
-
Mikhail Glushenkov
-
Moritz Kiefer