Several builds, like this one, fail when executing cabal check:
++cabal check
These warnings may cause trouble when distributing the package:
* 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit
and not just imposing longer compile times on your users.
However, most of the other builds in the matrix do not fail after this check.
I'm using the complex Travis configuration suggested at the stack docs, and this is the Travis configuration specific for the project I'm trying to get on CI.
Any ideas on what might be causing this behavior?
There are two types of build in your travis config:
Stack based build
Cabal based build
If you follow the script code, you will see that only Cabal based build has the command cabal check in it. That will explain why all of your Stack based builds are working fine. Now, let's see the cabal check command line in detail:
cabal check || [ "$CABALVER" == "1.16" ]
So, if your installed cabal version is 1.16, it will ignore the output of cabal check and that command is treated as a success. And infact, that's what is happening. Only one Cabal based build job is success in your travis, because it's version is 1.16.
Related
hello I am new to haskell/cabal so this might be a stupid question but i couldn't find it anywhere.
When I try to build a cabal package it correctly list the dependencies.
cabal build main
In order, the following will be built (use -v for more details):
- dependency-1.0
cabal: Failed to build dependency-1.0
so then I do
cabal build dependency
and it build fine listing the correct version. I go back to cabal build main and it still fails. And what is more weird when I go to build the dependency again it says build required
There are 2 questions. Why would it fail in the main if it build by itself just fine. And also even if I run cabal build dependency over and over it always says build required, like it isn't caching anything? Is this normal?
Running stack test --coverage generates a nice HTML report showing what lines your test suite covers. How can I achieve the same thing using cabal new-test?
I'm able to pass --enable-coverage to generate a .tix file but I'm not sure what to run on the .tix file to generate the HTML report. I'm pretty sure it involves hpc but I haven't been able to work out the right command.
I have the standard Cabal configuration of my application being a library, with a test-suite for that library.
It appears it's as easy as passing --enable-coverage to cabal new-test. I had previously been running tests with cabal new-run test:test to workaround some limitations of new-test (e.g. lacking streaming and colors), so the fix is to use new-test instead of new-run.
Cabal 3.6 should be able to generate the HPC report. There is one caveat; this error may appear:
Error:
Internal libraries only supported with per-component builds.
Per-component builds were disabled because program coverage is enabled
https://github.com/haskell/cabal/issues/6440
To avoid the error, add to cabal.project:
package *
coverage: True
library-coverage: True
then cabal test (without --enable-coverage). The report should be somewhere in dist-newstyle.
I was trying to add hdevtools to my stack project, so I ran stack build hdevtools. The install seemed to work successfully, and my text editor stopped reporting imported libraries installed via stack (like aeson and tasty) as missing.
However, things went wrong when I added this line to the dependencies section of my package.yaml file:
- hdevtools >= 0.1 && < 1
And then tried to run stack build again. I received the following error output:
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for my-app-name-0.1.0.0:
hdevtools is a library dependency, but the package provides no library
needed since my-app-name is a build target.
Some different approaches to resolving this:
* Consider trying 'stack solver', which uses the cabal-install solver to attempt
to find some working build configuration. This can be convenient when dealing
with many complicated constraint errors, but results may be unpredictable.
Plan construction failed.
I tried running stack solver, but that threw the exception documented here.
How can I declare hdevtools as a dependency of my project?
#alexis-king recommends using stack build --copy-compiler-tool hdevtools in this guide, in the section titled Setting up editor integration.
This works for the current project, and other projects using the same GHC version, but you will need to run it again when you upgrade to a new GHC version.
More context from King's guide:
As mentioned above, stack install is not what you want. Tools like ghc-mod, hlint, hoogle, weeder, and intero work best when installed as part of the sandbox, not globally, since that ensures they will match the current GHC version your project is using.
How can I declare hdevtools as a dependency of my project?
hdevtool is an executable and cabal doesn't have a concept of development dependencies (like in other package managers like npm etc). So, all you can do is install hdevtools globally and make it work.
The recent Travis CI build of the development version of my Haskell package reports the error
MissingH must match >=1.3.0.1, but the stack configuration has no specified version (latest matching version is 1.4.0.1)
when building for GHC 8.6.1, even though I have
MissingH >=1.3.0.1
in my build-depends.
I don't understand this error: it seems contradictory. I have no upper limit on MissingH, so why is it erroring and not using the latest?
You need to add MissingH to stack.yaml.
extra-deps:
- 'MissingH-1.4.0.1'
Your package's *.cabal file says what versions of dependencies are compatible with your package. It is a loose specification, not all combinations may actually work (because they may have conflicting bounds on transitive dependencies, or there is some unforeseen breakage with a particular version you haven't tested with).
In contrast, stack.yaml describes a particular snapshot of packages, pinned to specific versions. This precisely says "my package is known to work with those versions". Of course, it is tedious to maintain the version of every dependency, and for that the Stackage team maintains a "resolver", a curated set of package versions known to work together, that you can use to specify the version of many packages at once, by setting the resolver: field of stack.yaml appropriately. A resolver only lists a subset of packages on Hackage, so when one of your dependencies is not in there, you need to add it to your stack.yaml as an extra-dep.
Update: following the discussion, some more details about configuring travis are necessary.
First, my current preferred solution for CI of Haskell projects is to not bother with stack and use instead https://github.com/haskell-CI/haskell-ci which generates a travis script using cabal-install.
Now for a less radical solution.
Currently the travis script is only varying the --resolver option, but as far as I can tell there is no command line option to add an extra-dep. It seems stack.yaml files are the only way for that. Furthermore, we only want to specify MissingH as an extra-dep for the latest nightlies, because LTS'es already include it.
Thus I suggest the following:
Create a separate stack.yaml for the nightly resolver only, call it something else since you already have one, for example stack-nightly.yaml
packages:
- .
extra-deps:
- 'MissingH-1.4.0.1'
Set an environment variable to point to stack-nightly.yaml when the resolver is a nightly, maybe:
env:
...
- $RESOLVER=nightly STACK_YAML=stack-nightly.yaml
# Not sure of the syntax.
Otherwise you can use the --stack-yaml command line option.
stack new usually creates a default Setup.hs file. I removed it from a project and it still builds alright for any lts resolver down to lts-2. It also passes cabal check at least for cabal version 1.24. (Though not for cabal 1.22.)
Can I conclude from this result that including a default Setup.hs in a project is not trendy anymore and I can drop it? In particular, will many prospective users be diverted from installing the package if it's not passing cabal check for cabal 1.22?
P.S. This question is more specific than the other, similar one in that I want to know, specifically, if the package not passing cabal check for a certain version of cabal due to the absence of an otherwise unnecessary Setup.hs will be counted against that package in some situations, and whether there are any other downsides to not having a Setup.hs in a project, considering the current state of the Haskell ecosystem. Whether a Setup.hs is necessary or useful overall is not a question here.
If you run cabal sdist on a project without a Setup.hs file, cabal creates one for you -- try it!
As such, there's no point to removing the file, because it will just get regenerated when you package for distribution anyway.