[Scons-users] Launching gcov from SCons

[Pawel Tomulik]

W dniu 10.02.2012 14:52, Brian Cody pisze:

> On Fri, Feb 10, 2012 at 3:58 AM, Ringo De Smet <ringo.desmet at gmail.com

> <mailto:ringo.desmet at gmail.com>> wrote:

>

>     Brian,

>

>     On 7 February 2012 15:37, Brian Cody <brian.j.cody at gmail.com

>     <mailto:brian.j.cody at gmail.com>> wrote:

>

>         Things that would work for me:

>         If I could call a function where I pass in an Object and I

>         receive the source File or (or path) that generated it.

>         If I could call a function where I pass in a source file and

>         receive the Object (or path) that was compiled previously.

>

>

>     If you build with coverage, do you also have a custom emitter that

>     adds nodes for the gcno and gcda files? That would be my way of

>     working. Once you have these nodes, you can pass these to the gcov

>     builder, also with an emitter that filters out the .o files and only

>     takes in the gcno/gcda nodes to generate your report.

>

>     Ringo

>

>

> I have not tried that, but that sounds interesting. The gcda files

> aren't actually generated until the application is run, so would the

> emitter have to somehow know when you run a unit test which objects are

> involved in that executable?

>

> I have a solution now that seems good enough. The builder now accepts as

> a target a file to contain a summary of code coverage information. The

> source contains a list of all the objects that went into the executable.

> For each object, we call the SCons function FindSourceFiles. From that

> list, we determine which source files are actually in our project (we

> don't care about the coverage of internal compiler libraries). We also

> determine which of the source files actually caused the object to be

> created (name.cpp -> name.o). For each cpp->o pair, we call gcov. We

> compare the files listed in gcov's coverage to those determined to be in

> our project and record the relevant information for creating our summary.

>

> One caveat to this implementation is it won't work in projects where to

> .cpp files have the same name, but I don't think that's a possibility to

> us since we'd need to have two clsases with the same name in the same

> executable.

>

>

> -Brian


I know it's a long time since this thread started, but if someone is 
still interested, there is a tool: 
https://github.com/ptomulik/scons-tool-gcccov which addresses dependency 
issues.

-- 
Paweł Tomulik