CODEWITHSUNDEEP
c++boostcode-coveragegcovbjam
aSteve
aSteve

Reputation: 2016

Bjam for gcov coverage analysis?

I am looking to integrate a non-trivial cross-platform build system for a project predominately written in C++. I've evaluated Cmake and Scons, so far, and while they both represent an improvement over (GNU) make, neither approach seemed either elegant or transparent in the context I was trying to use these tools. This brought me to Boost Build (Bjam) and I am encouraged that, given my project is dependent upon Boost, bjam should be available for any viable target platform already.

I've run into difficulty trying to neatly integrate code-coverage for unit tests of a library... with a view to eventual integration into a build server such as Jenkins. While I'm willing to be guided by Bjam best/standard practice, I think I need three distinct "variants":

Essentially, in addition to the standard debug and release builds, I'd like a special purpose debug build that also collects coverage data.

I need to build with (at least) g++ and msvc... and use gcov switches only with g++. This means my library target needs different "compilerflags" to the unit-test executable target... and only for one of my compiler suites... and for only one variant.

I am unclear how best to achieve this with Bjam - though, I suspect, it should be a fairly common use case. Does Bjam have explicit support for gcov coverage analysis (possibly presenting results using lcov)? If not, can anyone recommend a strategy which would support the above (simplified) scenario?

Upvotes: 6

Views: 885

Answers (2)

kriss
kriss

Reputation: 24177

I have the same need and I basically added the lines below to define my own coverage variant in my Jamroot file.

variant coverage : debug : <cxxflags>--profile-arcs <cxxflags>--test-coverage <cxxflags>--coverage <link>shared ;
lib gcov : : <name>gcov : ;

unit-test mytest : tests/mytest.cpp libboost_unit_test : <variant>coverage:<library>gcov ;

The coverage data is created when the test is run and I exploit it afterward outside of bjam using gcov.

Upvotes: 1

Garen
Garen

Reputation: 961

I'm pretty confident that the answer to your first question--whether bjam has explicit support for gcov--is a definite no, because like debug and release build configurations, bjam would consider that to be a feature variant for the user to define.

For bjam, it looks like there are a couple ways to do what you want:

  1. Define your own feature variant and then update the CONFIG_COMMAND for any custom flags.

  2. Define/redefine a toolset.

For CMake, consider following the pattern that ITK does:

http://cmake.org/Wiki/ITK/Policy_and_Procedure_for_Adding_Dashboards#Configuring_GCOV_Coverage

Upvotes: 1

Related Questions