You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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).
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.The text was updated successfully, but these errors were encountered: