Bjam para el análisis de cobertura de gcov?

Question

Estoy buscando integrar un sistema de compilación multiplataforma no trivial para un proyecto escrito predominantemente en C++. He evaluado Cmake y Scons, hasta el momento, y aunque ambos representan una mejora sobre la marca (GNU), ninguno de los dos enfoques parecía elegante o transparente en el contexto que estaba tratando de utilizar. Esto me llevó a Boost Build (Bjam) y me alienta que, dado que mi proyecto depende de Boost, bjam ya debería estar disponible para cualquier plataforma de destino viable .

He tenido dificultades para tratar de integrar prolijamente la cobertura de código para las pruebas unitarias de una biblioteca ... con vistas a una eventual integración en un servidor de compilación como Jenkins. Mientras estoy dispuesto a ser guiado por bjam mejores prácticas/estándar, creo que necesito tres "variantes" distintas:

• liberación - para construir la biblioteca estática optimizada única
• de depuración - para construir no optimizado estática pruebas de biblioteca y unidad
• cobertura - para compilar biblioteca habilitada para cobertura y vincular con pruebas de unidades no habilitadas para cobertura.

Esencialmente, además de las versiones estándar de depuración y liberación, me gustaría una compilación de depuración especial que también recopile datos de cobertura.

Necesito construir con (al menos) g ++ y msvc ... y usar los conmutadores gcov solo con g ++. Esto significa que mi biblioteca objetivo necesita diferentes "compilerflags" para el objetivo ejecutable de prueba de unidad ... y solo para uno de mis compiladores ... y para una sola variante.

No tengo claro cuál es la mejor manera de lograrlo con Bjam, aunque sospecho que debería ser un caso de uso bastante común. ¿Bjam tiene soporte explícito para el análisis de cobertura de gcov (posiblemente presentando los resultados usando lcov)? De lo contrario, ¿alguien puede recomendar una estrategia que respalde el escenario anterior (simplificado)?

Answer 1

Estoy bastante seguro de que la respuesta a la primera pregunta - si bjam tiene un apoyo explícito a gcov - es un sitio de paso sin, porque al igual que depurar y liberar crear configuraciones, bjam consideraría que para ser un feature variant para que el usuario lo defina

Para bjam, parece que hay un par de maneras de hacer lo que quiere:

y

1. Define your own feature variant continuación, actualizar el CONFIG_COMMAND de las banderas de encargo.

2. Define/redefine a toolset.

Para CMake, considere siguiendo el patrón que ITK hace:

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

Answer 2

tengo la misma necesidad y básicamente añadido las líneas de abajo para definir mi propia variante de la cobertura en mi archivo Jamroot.

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 ; 

se crean los datos de cobertura cuando se ejecuta la prueba y que se aprovechan de ella después fuera del bjam usando gcov.