create baseline '--initial' before or after you build your (gcov) project ?

[abazaba855]

Hi,

I have been reading about using '--initial' (in order to create a basline) in the manual pages, and feel this is indeed the right way to use the tool. However, I have a small question about the order of the commands that you run. The lcov manual page (on '--initial') tells you to do this :

1. create baseline coverage data file # lcov -c -i -d appdir -o app_base.info

2. perform test # appdir/test

3. create test coverage data file # lcov -c -d appdir -o app_test.info

4. combine baseline and test coverage data # lcov -a app_base.info -a app_test.info -o app_total.info

However, it does not say if you should build your project (with coverage *FLAGS) before or after you run step '1' in this example ? So, should you build your project as step '0' in this example (before '1'), or between steps '1' and '2'. ? My gut feeling tells me you should build your project before creating the baseline, but I decided to ask this here just in case I interpret things incorrectly.

[henry2cox]

Your intuition is correct: you have to build the code first. The instrumentation has to exist before you can collect any data.

[abazaba855]

Thanks.

Come to think of it, what about the following scenario :

What if you have a previous full build of your project, and then add some code and want to see the lcov results (of the entire project) :

1.) Do you have to do a full 'make clean && make', or is it ok to let make just build the changed code, so just run 'make' (without a previous 'make clean'), and then run lcov again ?

2.) Regardless of whether you do a 'make clean && make' or just 'make', I assume that you need to reset the counters (with 'lcov --zerocounters') after you do the build ?

Sorry if this all seems obvious.

[henry2cox]

Again – your intuition is correct (you need to rebuild – but only really need to rebuid the parts that changed). Selectively rebuilding is somewhat fraught in any real, significant project though. Dependencies don’t always get tracked the way you might hope.

You may also want to check out the ‘differential coverage’ tools for the case that your project changed and you want to compare coverage of your baseline version of code and tests to your current version of code and tests. Your revision control system will have kept track of code changes, and you can simply hang on to the ‘.info’ files that you got from your baseline regression execution.

Henry

[abazaba855]

Thank you.

These 'differential coverage' tools sound interesting. But I cannot seem to locate them in this repository, perhaps I am simply looking in the wrong places ?

[henry2cox]

The link to pull request #86 will get you to the code and to some papers which discuss the idea and some possible use models.

[henry2cox]

The differential coverage features mentioned above have been merged to TOT. Please see the updated README for pointers to some of the new features. In the interest of cleaning up the lcov issue list, I am going to close this one now - as I believe the the set of questions have been answered. Please reopen or file a new request, if you feel that something is unresolved. I can pretty much guarantee that someone else will have the same questions and see the same issues as you. Similarly, features that you would find useful are very likely to also be useful to others - and so we should think about what else we might want, and then implement that. Hope this helps Henry