Bjam for gcov coverage analysis?

Question

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":

• release - to build optimised static library only
• debug - to build non-optimised static library and unit tests
• coverage - to build coverage-enabled library and link with non-coverage enabled unit tests.

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?

Answer 1

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