Coverage #682
Coverage #682
Conversation
From https://github.com/bilke/cmake-modules commit 877bab9dd1b17468c5d939cacaa2ad7ba99d1977 Signed-off-by: Marcus Müller <[email protected]>
Requirements: - gcc or clang - gcov - gcovr Usage: ```shell mkdir build-coverage && cd build-coverage cmake -DCMAKE_BUILD_TYPE=Coverage .. make -j make coverage firefox coverage/index.html ``` Signed-off-by: Marcus Müller <[email protected]>
This makes clang-16 builds possible. Signed-off-by: Marcus Müller <[email protected]>
|
The patch to CodeCoverage.cmake is something I'm trying to upstream: bilke/cmake-modules#82 |
Signed-off-by: Marcus Müller <[email protected]>
|
@jdemel done, but you won't be updating this anytime soon. |
That is actually a good reason to put the info in there. |
There was a problem hiding this comment.
The direct HTML output is nice, but actually the regular coverage info can be post-processed with tools to give you HTML as you wish. Therefore it would be better if we would produce regular coverage output and not HTML.
Would it be possible for you to add a github workflow which will run and produce codecov artifacts and uploads them with codecov-action so we can hook it into codecov.io?
| ######################################################################## | ||
| # Setup Coverage | ||
| ######################################################################## | ||
| if(${CMAKE_BUILD_TYPE} STREQUAL "Coverage") |
There was a problem hiding this comment.
With the CodeCoverage.cmake setting the Build_Type to anything other than Debug results in a warning. Either removing that check from there or leaving the CMAKE_BUILD_TYPE alone and just adding a switch to enable coverage would be an option.
There was a problem hiding this comment.
this is honestly just a mirror of what GR does; looking back, yes, having extra flags instead of a build type of its own would have been a worthwhile option, but I foreseeable won't have time to implement that.
| # modifications as done in the past for GNU Radio. | ||
| include(CodeCoverage) | ||
| append_coverage_compiler_flags() | ||
| setup_target_for_coverage_gcovr_html( |
There was a problem hiding this comment.
Why only html output and why gcovr? IIRC lcov is the more mature and complete tool. Allowing regular coverage output we can hook that into codecov.io pipelines and add information to pullrequests and pushes to track coverage as we go.
There was a problem hiding this comment.
gcov vs lcov:
TBH, because I looked into lcov first, couldn't make it work, and then resorted to doing what was possible within limited time :)
html:
because I wanted this to be immediately useful for insights, and hence jumped on a minimum effort way of getting readable output. Proper CI integration, including things like complaining when you add code that is specifically not well-covered, is something that needs to come – but having this seemed better than not having it.
There was a problem hiding this comment.
gcov vs lcov:
TBH, because I looked into lcov first, couldn't make it work, and then resorted to doing what was possible within limited time :)
html:
because I wanted this to be immediately useful for insights, and hence jumped on a minimum effort way of getting readable output. Proper CI integration, including things like complaining when you add code that is specifically not well-covered, is something that needs to come – but having this seemed better than not having it.
|
@marcusmueller If you don't mind I'll have a crack at it to make it useful for user output & ingestion into statistics/CI pipeline. Because with the way it is right now it will not be immediately useful to integrate... |
This adds support for Coverage reporting.
Requirements:
Usage:
Demo of the result on my oldish desktop machine: https://doppler.inpha.se/coverage/