Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Properly support code coverage reporting in the cov target #20

Open
nicholatian opened this issue Mar 5, 2021 · 3 comments
Open

Properly support code coverage reporting in the cov target #20

nicholatian opened this issue Mar 5, 2021 · 3 comments
Labels

Comments

@nicholatian
Copy link
Member

The cov target is the default for compiling test batteries, but historically it has not actually reported code coverage information. Provide a mechanism to have this reported.

@nicholatian nicholatian added the bug label Mar 5, 2021
@nicholatian
Copy link
Member Author

It seems this will also involve introducing a new .PHONY target to generate code coverage reporting. I will name this target report, so users run make report to generate and read the code coverage report. This will also involve a new public symbol $COV and its flags $COVFLAGS, which should be included in a documentation update.

@nicholatian
Copy link
Member Author

It seems that the best workflow for reporting code coverage requires a small hack. Instead of mangling target filenames to have their *.prof{raw,data} artefacts side-by-side, Slick will roll with a default.prof{raw,data} in the repository root for whichever test battery is being dealt with. This means that we do not need to do the insane acrobatics likely necessary to properly transform and synchronise the LLVM_PROFILE_FILE variable. However, the user will have to specify FILE=src/their_battery.c.tes to inform the report generator of which module was analysed.

In other news, code coverage generation is mostly present. I can’t wait to awk the output and display it on a webpage.

@nicholatian
Copy link
Member Author

Work on GNU code coverage has not been implemented, nor is it known how feasible it will be on host platforms outside of Linux. Also yet to be investigated is the feasibility of code coverage when cross-compiling, for all such embedded platforms (trialing Windows with WINE would be a good start).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

1 participant