We use a coverage tool Bullseye which provides an additional coverage file when you compile/link with their compiler/linker shims.
We currently shim the compiler/linker and zip the output into one file to get caching working with this tool, however we would prefer to declare an extra output in the toolchain when we are using the coverage toolchain.
I think what we would want to do is:
Tell bazel about the bullseye compiler wrapper and specify via data its reliance on the original compiler. Specify there is an:
additional_output_groups = {
"coverage_files": ["$(executable_name).cov"],
}
Then I think we can just use cc_arg as normal with make variable substitutions.
After that we can use aspects to easily gather the additional output_groups and merge the .cov files.
Additionally I think this can help support other compiler features which aren't just produce and object file and produce a executable. There are plenty of additional Microsoft CL features for example.
We use a coverage tool Bullseye which provides an additional coverage file when you compile/link with their compiler/linker shims.
We currently shim the compiler/linker and zip the output into one file to get caching working with this tool, however we would prefer to declare an extra output in the toolchain when we are using the coverage toolchain.
I think what we would want to do is:
Tell bazel about the bullseye compiler wrapper and specify via data its reliance on the original compiler. Specify there is an:
Then I think we can just use
cc_argas normal with make variable substitutions.After that we can use aspects to easily gather the additional output_groups and merge the .cov files.
Additionally I think this can help support other compiler features which aren't just produce and object file and produce a executable. There are plenty of additional Microsoft CL features for example.