linux-test-project / lcov

LCOV
GNU General Public License v2.0
867 stars 235 forks source link

Extracting data from a diffcov report #205

Closed tomfbailey closed 1 year ago

tomfbailey commented 1 year ago

Hi,

I've created an lcov coverage report using differential coverage and date binning. Is there a way to extract the values for each of the cells in the html file easily?

image Some of the stats are printed out when running genhtml (as we can see here) which is a little easier to parse but is there a way to extract date binned information in the same way (the kind of data seen below)?

image Thanks!

henry2cox commented 1 year ago

Yes and no ... :-)

If you want only the summary information (the line/function/branch table at the top of the page), possibly the easiest solution is to use the '--criteria-script' callback. The callback is passed the summary information in JSON format. There is a sample script called 'criteria' in the release that you may be able to modify to meet your needs. It turns out that at least one internal group uses exactly this to generate summary reports (ASCII) for each module/module owner. (Module ownership doesn't exactly match directory structure and/or can span multiple directories...that information is encoded elsewhere, and is another input to their callback script.)

The bad news is that - as of today - the callback gets only the summary information - not the binning information. It is obviously not that hard to pass more data to the callback - but that does require some small changes to the 'genhtml' implementation. I didn't do that because we didn't need it in our existing use. cases.

Hope this helps.

Henry

tomfbailey commented 1 year ago

Thanks for the swift response Henry - I'll have a look at the callback and figure out a workaround for extracting the binning data :+1:

henry2cox commented 1 year ago

No worries. Just to be clear: differential categorization data IS there in the callback. Date/owner binning data is not. (But not hard to add it).

The other option (which I also did not do) is to serialize the coverage DB. Then you would have all the information - and could do whatever you want. That isn't hard to do either, as all of the hooks are already there (...because they are used to implement parallel processing).

I also admit to being curious about your actual application. Feel free to ping me directly if you want (not hard to figure out my email address).

Henry