Lcov/gcov integration for Gedit

[jdpipe]

Hi all
Not an issue, but perhaps something you might like to note in your README file for lcov.
I've written an integration for Gcov/Lcov into Gedit, which does highlighting of coverage, including differential coverage, in Gedit.
The gedit plugin can be installed using scons install and will pick up lcov output from a .lcov folder in the project root, and use it as the basis for file highlighting.
See here for details, including screenshot.
https://github.com/ascend4/ascend4/blob/python3/tools/gedit/gcov/README.md
Cheers
JP

[henry2cox]

Thanks for the pointer. I'm not entirely sure how to put this into the lcov readme - as that doc doesn't currently have any references to complimentary tools and plugins. Open to suggestion.
For the moment, though: this would probably be best as a discussion item on github.
I don't know if people search for or look at discussion items - but they have the advantage of not getting closed/not getting automatically ignored.

Two minor comments on the README.md link above...while it mentions differential coverage and I know what that must mean (in the context of lcov, at least) - it is very possible that some of your users do not - so it might be useful to either briefly explain or insert a pointer to additional information.
I'm curious if your plugin deals with --select-script callbacks - which we use especially in code review.

Henry

[jdpipe]

Hi Henry

Thanks for the feedback. I added some explanation of 'differential coverage' to the README.md, hope it's clearer now.

The current implementation here is in gcov.py. For 'standard' coverage analysis, it uses gcov directly to process .gcno and .gcda files into JSON data that is then parsed and applied line-by-line using the 'tag' feature in Gedit.

For differential coverage analysis, it's assumed that the user has run lcov for themselves, in order to set the baseline, as suggested in the README. The suggested lcov command is

lcov --capture --directory . --output-file .lcov/base.info --rc check_data_consistency=0 

This produces only a .info output file, and that file is parsed in gcov.py in the method _load_baseline. The variant ('current' in the code) is still parsed using gcov as for the 'standard' coverage. So the tool is using a combination of 'lcov and gcov, benefiting from the fact that lcov stores all of coverage for all of the files in a single .info file. This means you can flip between different source code files in different tabs/windows, and the coverage for each one can be quickly applied.

I'd welcome any thoughts on ways of making this easier. Perhaps the 'calculate baseline' step could be added via a button in Gedit somehow, but I didn't yet work out a way to do that.

Cheers
JP

[henry2cox]

At least in most cases I see: the source code is changing along with the tests - so the differential categorization needs to account for missing and new lines - otherwise, the baseline data can't be compared to current.
So I think your integration is missing some functionality.

As far as clarifying differential coverage...I suspect that the easiest and most complete approach is to include a reference (hyperlink, to somewhere useful).

[jdpipe]

Interesting! Changing source code was not part of my use-case, but I can see that it would normally be so. I added a link to your paper on arXiv. I see that this would add significant complexity to the task, which my approach doesn't address at all. Do you have any ideas for how I could leverage lcov to implement this differential analysis in a better way in Gedit? Seems like using git diff could be a way of mapping the baseline to variant lines fairly reliably...?

[henry2cox]

Right. git diff output is very close to the universal diff format that genhtml knows how to handle. There is a gitdiff script in the lcov scripts directory which does the required munging. Similarly, there is a p4udff script that does the same thing - for perforce.
The main difference between them is that gitdiff wants to look at branches whereas p4udiff will also look at differences which are not checked in. git branches are so lightweight that it didn't make sense to NOT use them.

I didn't take a close look at your code. As you say: there are 12 differential categories (10, if you don't consider 'deleted' code, which won't appear in the editor). That makes categorization a bit more complex because you need to both map where lines came from/went to as well as whether they were covered/not covered/not code in the past.
I think it would not be too difficult to common-ize the genhtml categorization implementation to make it emit a differential coverage DB (e.g., via yet another callback) - though right now, it builds the DB for its own use but does not save it for you.
Another approach is to screen-scrape the HTML files...but that is both really painful and prone to breakage when/if the HTML changes.

A utility to save the differential DB seems like a worthy project/something worth merging if someone was to implement it.

(Edit 18 Sept/2025: forgot to mention that the genhtml --serialize ... option will save the coverage DB.
That might not be exactly what you want, though - as the storage format is Perl::Storable - which is very easy to handle, if you are writing in Perl - but not so easy if you aren't.)