Bjam for gcov coverage analysis?

I want to integrate a non-trivial cross-platform build system for a project primarily written in C ++. So far, I have been evaluating Cmake and Scons, and although both of them represent an improvement over (GNU), neither approach seems elegant or transparent in context. I tried to use these tools. This led me to Boost Build (Bjam), and I was pleased that, given that my project depends on Boost, bjam should be available for any viable target platform already.

I ran into difficulties trying to neatly integrate code coverage for unit tests of the library ... with the goal of integrating into a build server such as Jenkins. Although I am ready to be guided by Bjam best practice / standard practice, it seems to me that I need three different β€œoptions”:

  • release - to create only an optimized static library
  • debug - for creating a non-optimized static library and unit tests
  • coverage - creating a library with coverage support and linking with unit tests not included in the coverage area.

In fact, in addition to the standard debugging and release collections, I need a special 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 that my target library needs different "compiler flags" for the unit-test executable ... and only for one of my compiler sets ... and for only one option.

I do not understand how best to achieve this with Bjam - although, I suspect, this should be a fairly common use case. Does Bjam have explicit support for gcov coverage analysis (possibly presenting results using lcov)? If not, can someone recommend a strategy that supports the above (simplified) scenario?

+6
source share
2 answers

I am sure that the answer to your first question is whether bjam has explicit support for gcov - this is a definite no , because, like the debug and release configurations, bjam will assume that for a function variant it is for the user to define.

For bjam, there seem to be several ways to do what you want:

For CMake, consider the pattern that ITK does:

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

+1
source

I have the same need, and I basically added the lines below to define my own cover option 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 ; 

Coverage data is generated when the test starts, and I use it later outside of bjam using gcov.

+1
source

Source: https://habr.com/ru/post/916120/


All Articles