Improve programmatic access

[bracco23]

I'm working on using gcovr to parse output on our unit tests.

Since invocation of gcovr from the command line is slow, I opted to import all the relevant processing data from a custom script which basically execute tests, collects gcda files and invokes gcov on them in the right folder, uses gcovr parsing functionalities to print html and xml outputs.

What I noticed is that the different functions rely heavily on the options passed to the main script, so much that I had to recreate the object and customize.

It would be much better to not use the command line options in any module different than the main one so that other modules can use them without having to rely on the same object.

For example, print_html_report takes covdata and options as input. It is cleaner to pass the flags as separate parameters or as a custom HTMLOptions object, so that it can be used by other scripts in a much simpler way.

[latk]

I agree, feel free to refactor. If you figure out a sensible interface that will work for all generators, I'd be open to exposing that as an API for Python scripts (right now, I consider everything internal/private).

But please be warned that I'm seriously behind on reviewing & merging PRs

[chenlijun99]

@Spacetown Hi. I see that you closed this issue as completed in March 19. However I couldn't find any documentation about programmatic APIs for gcovr. I tried also to look through some commits near March 19 as well as read the changelog of gcovr 5.1 (released in March 26), but couldn't find anything.
Did I misinterpret the "closed as completed" and in reality no API has been exposed?

[latk]

@chenlijun99 Correct, no API has been exposed. At this time, gcovr only supports interaction via its command line interface. But you can “extend” coverage processing by manipulating the JSON output format. For example, if you want to customize coverage exclusion processing, you could do:

# 1. collect coverage data
gcovr --json raw-coverage.json

# 2. modify the JSON file as needed
./your-custom-filter <raw-coverage.json >processed-coverage.json

# 3. use gcovr to output a coverage report
gcovr -a processed-coverage.json --html-details report.html

At the time when this issue was closed, GitHub did not distinguish between “close as completed” and “close as not planned”. That feature was introduced two months later.

[chenlijun99]

@latk Thanks for the suggestion! Thanks also for the GitHub history lesson 😄 !

[Spacetown]

Good to know that we can now close as not planned.