Bjam per analisi della copertura gcov?

Question

Sto cercando di integrare un sistema di compilazione multipiattaforma non banale per un progetto scritto prevalentemente in C++. Ho valutato Cmake e Scons, finora, e mentre entrambi rappresentano un miglioramento rispetto a (GNU), nessun approccio sembrava elegante o trasparente nel contesto che stavo cercando di utilizzare questi strumenti. Questo mi ha portato a Boost Build (Bjam) e sono incoraggiato che, dato che il mio progetto dipende da Boost, bjam dovrebbe essere già disponibile per qualsiasi piattaforma target valida .

ho incontrato difficoltà cercando di integrare perfettamente il codice-copertura per i test di unità di una libreria ... in vista di eventuale integrazione in un build server, come Jenkins. Mentre io sono disposto a essere guidata da bjam migliori pratiche/normale, penso che ho bisogno di tre "varianti" distinti:

• rilascio - per costruire libreria statica ottimizzata solo
• di debug - per costruire non ottimizzati statica library e unit test
• coverage - per creare librerie e collegamenti abilitati alla copertura con test unitari non coperti da copertura.

In sostanza, oltre al debug e build di rilascio di serie, Vorrei una speciale costruzione scopo di debug che raccoglie anche i dati di copertura.

Ho bisogno di compilare con (almeno) g ++ e msvc ... e utilizzare gli switch gcov solo con g ++. Questo significa che il mio target di libreria ha bisogno di diversi "compilatori" per il target eseguibile del test unitario ... e solo per una delle mie suite di compilatori ... e per una sola variante.

Non sono chiaro come ottenere questo risultato con Bjam, anche se, sospetto, dovrebbe essere un caso d'uso abbastanza comune. Bjam ha il supporto esplicito per l'analisi della copertura gcov (possibilmente presentando i risultati usando lcov)? In caso negativo, qualcuno può raccomandare una strategia che supporti lo scenario (semplificato) sopra riportato?

Answer 1

Sono abbastanza fiducioso che la risposta alla tua prima domanda - se bjam ha supporto esplicito per gcov - è un preciso non, perché come eseguire il debug e rilasciare costruire configurazioni, bjam prenderebbe in considerazione che per essere un feature variant per l'utente da definire.

Per bjam, sembra che ci sono un paio di modi per fare ciò che si vuole:

1. Define your own feature variant e quindi aggiornare il CONFIG_COMMAND per eventuali bandiere personalizzate.

2. Define/redefine a toolset.

Per CMake, considerare seguendo lo schema che ITK fa:

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

Answer 2

ho la stessa necessità e io fondamentalmente aggiunto le linee di seguito per definire la mia variante di copertura nel mio file 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 ; 

I dati di copertura viene creato quando viene eseguito il test e ho sfruttarla in seguito al di fuori del bjam usando gcov.