cabal new-test --enable-coverage fails #5433
Comments
|
I looked at this a bit more. But the correct execution of |
|
Edit: ignore this comment, I was reading a bad copy/paste |
|
It roughly looks like |
|
/cc @ttuegel |
|
I think this has a symptom in common with (or might even be a duplicate of) #5213. |
|
Yea, I did have a feeling it'd be the same bug, but wasn't entirely sure. |
|
I am getting by this too. Is there any known solution? I am on GHC 8.4.3 with Cabal lib 2.2.0.1 and cabal-install 2.2.0.0 on Debian. |
|
Duplicate of #5213 |
|
I am not convinced this is a duplicate of #5213. That issue is about a single Cabal package not working, and part of that bug is probably here. But this bug is about other libraries not being picked up. Another example came up today:
We see there is no mention to The correct invocation of |
|
The other alternative invocation is I think what is problematic is that all libraries in the Could a Cabal dev confirm that? |
3 tasks
ocharles
added a commit
to ocharles/cabal
that referenced
this issue
Apr 10, 2021
Currently, if you have multiple packages in a project and try and run the test suite of a single package with --enable-coverage, hpc will fail to run. The problem is that _all_ dependencies of the package are built with `-fhpc`, but when we run `hpc markup`, we are only passing the `.mix` directory of the package being tested. Because we built all dependencies with `-fhpc` and we haven't excluded them from the report, we need to supply their `.mix` directories too. The above suggests one fix - compute the transitive closure of all `.mix` directories. However, there is another solution - change from using an exclude-list to using an include-list. This is the approach used in this commit. Explicitly enumerating all modules to _include_ in the report is simpler to code, but is also more likely to be what the user is interested in. Generally, when one generates a coverage report from a test-suite, they want to understand the coverage of the unit being tested. Having coverage information from dependencies is usually not relevant. This is also the behavior from old-style Cabal builds, where there wasn't even a notion of a Cabal project. Fixes haskell#5433.
hololeap
pushed a commit
to hololeap/cabal
that referenced
this issue
Apr 24, 2022
Currently, if you have multiple packages in a project and try and run the test suite of a single package with --enable-coverage, hpc will fail to run. The problem is that _all_ dependencies of the package are built with `-fhpc`, but when we run `hpc markup`, we are only passing the `.mix` directory of the package being tested. Because we built all dependencies with `-fhpc` and we haven't excluded them from the report, we need to supply their `.mix` directories too. The above suggests one fix - compute the transitive closure of all `.mix` directories. However, there is another solution - change from using an exclude-list to using an include-list. This is the approach used in this commit. Explicitly enumerating all modules to _include_ in the report is simpler to code, but is also more likely to be what the user is interested in. Generally, when one generates a coverage report from a test-suite, they want to understand the coverage of the unit being tested. Having coverage information from dependencies is usually not relevant. This is also the behavior from old-style Cabal builds, where there wasn't even a notion of a Cabal project. Fixes haskell#5433.
hololeap
pushed a commit
to hololeap/cabal
that referenced
this issue
Apr 24, 2022
Currently, if you have multiple packages in a project and try and run the test suite of a single package with --enable-coverage, hpc will fail to run. The problem is that _all_ dependencies of the package are built with `-fhpc`, but when we run `hpc markup`, we are only passing the `.mix` directory of the package being tested. Because we built all dependencies with `-fhpc` and we haven't excluded them from the report, we need to supply their `.mix` directories too. The above suggests one fix - compute the transitive closure of all `.mix` directories. However, there is another solution - change from using an exclude-list to using an include-list. This is the approach used in this commit. Explicitly enumerating all modules to _include_ in the report is simpler to code, but is also more likely to be what the user is interested in. Generally, when one generates a coverage report from a test-suite, they want to understand the coverage of the unit being tested. Having coverage information from dependencies is usually not relevant. This is also the behavior from old-style Cabal builds, where there wasn't even a notion of a Cabal project. Fixes haskell#5433.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I don't have a minimal example at the moment sadly, but:
The text was updated successfully, but these errors were encountered: