Open
Conversation
- Allow user to specify "package directories" corresponding to the source directories of packages in a cabal.project. - Add functionality required to allow the user to specify the hpc data search directories explicitly, rather than searching for it in the usual places. This is primarily motivated by the Nix package manager, where hpc output is usally written to some folder outside of the current directory (e.g. to /nix/store/HASH-my-lib-0.1.0.0/share/hpc) as well as cabal.projects, where the hpc output directory might be "dist-newstyle/build/$platform/$compiler/$package/hpc". Multiple hpc directories can be specified, for e.g., one for each package in a cabal.project. - The filepath listed in a mix file doesn't include the sub-directory of the package in a cabal.project. So for cabal.projects, the filepath used as the index in the TestSuiteCoverageData is now prefixed with the sub-directory of the package. The behaviour when not using the "--package-dir" argument, or when using "--package-dir ./" is unchanged. - Gave a Monoid instance to TestSuiteCoverageData so we can easily use folds to sum the data up. - Separated the coveralls.io specific logic and the coverage data logic. The coverage data could be re-used for other coveralls-style tools. - Source files are now excluded before searching for them, so that if the file does not exist, it does not throw an error (primarily motivated by out-of-source builds such as Nix, where modules such as Path_library.hs can't be found in the build directory). - Changed the structure of getCoverageData a little, and added some commentary, so each of the steps required to read all the coverage data are a bit clearer.
Contributor
Author
|
cc @guillaume-nargeot |
2e3057c to
80d8c82
Compare
|
This repository seems dead years now... I cannot even make it work with the new Cabal 3.0.0 and GHC >= 8.8. |
Contributor
Author
|
@JasonSome Yep, I've figured as much. As for working with newer versions of Cabal, this might help: sevanspowell@3193755 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
source directories of packages in a cabal.project.
search directories explicitly, rather than searching for it in the
usual places. This is primarily motivated by the Nix package
manager, where hpc output is usally written to some folder outside
of the current directory (e.g. to
/nix/store/HASH-my-lib-0.1.0.0/share/hpc) as well as cabal.projects,
where the hpc output directory might be
"dist-newstyle/build/$platform/$compiler/$package/hpc". Multiple hpc
directories can be specified, for e.g., one for each package in a
cabal.project.
of the package in a cabal.project. So for cabal.projects, the
filepath used as the index in the TestSuiteCoverageData is now
prefixed with the sub-directory of the package. The behaviour when
not using the "--package-dir" argument, or when using "--package-dir
./" is unchanged.
folds to sum the data up.
logic. The coverage data could be re-used for other coveralls-style
tools.
the file does not exist, it does not throw an error (primarily
motivated by out-of-source builds such as Nix, where modules such as
Path_library.hs can't be found in the build directory).
commentary, so each of the steps required to read all the coverage
data are a bit clearer.