Bjam dla analizy zasięgu gcov?

Question

Chciałbym zintegrować niebanalny międzyplatformowy system kompilacji dla projektu napisanego głównie w języku C++. Do tej pory oceniłem Cmake i Scons, i chociaż oba stanowią ulepszenie w stosunku do (GNU) make, żadne podejście nie wydawało się ani eleganckie ani przezroczyste w kontekście, w którym próbowałem użyć tych narzędzi. To doprowadziło mnie do Boost Build (Bjam) i jestem przekonany, że biorąc pod uwagę, że mój projekt zależy od Boost, bjam powinien już być dostępny dla każdej realnej platformy docelowej .

Wpadłem w trudność, starając się starannie zintegrować zasięg kodu dla testów jednostkowych biblioteki ... z myślą o ewentualnej integracji z serwerem kompilacji, takim jak Jenkins. Chociaż jestem skłonny kierować Bjam najlepszy/standardowej praktyki, myślę, że potrzebne są trzy różne „warianty”:

• Release - budowy zoptymalizowaną bibliotekę statyczną tylko
• debug - do budowy nieoptymalizowanym statyczne testowanie biblioteki i jednostki testowej
• pokrycia - aby zbudować bibliotekę z włączonym zabezpieczeniem i link z włączonymi testami jednostkowymi bez zasięgu.

Zasadniczo, oprócz standardowych wersji debugowania i wydań, chciałbym utworzyć kompilację specjalnego przeznaczenia, która również zbiera dane dotyczące zasięgu.

Potrzebuję zbudować z (co najmniej) g ++ i msvc ... i używać przełączników gcov tylko z g ++. Oznacza to, że mój cel biblioteki potrzebuje różnych "flag kompilacji" do wykonywanego obiektu testowego jednostki ... i tylko dla jednego z moich zestawów kompilatorów ... i tylko dla jednego wariantu.

Jestem niejasny, jak najlepiej to osiągnąć z Bjam - choć podejrzewam, że powinien to być dość powszechny przypadek użycia. Czy Bjam ma jawne wsparcie dla analizy zasięgu gcov (ewentualnie prezentując wyniki używając lcov)? Jeśli nie, czy ktoś może zalecić strategię, która wspierałaby powyższy (uproszczony) scenariusz?

Answer 1

jestem całkiem przekonany, że odpowiedź na pierwsze pytanie - czy bjam ma wyraźne wsparcie dla gcov - jest definitywna nr, bo jak debugowania i zwolnij budować konfiguracje, bjam uznałby, że aby być feature variant do zdefiniowania przez użytkownika.

Dla bjam, wygląda na to, istnieje kilka sposobów, aby robić to, co chcesz:

1. Define your own feature variant a następnie zaktualizować CONFIG_COMMAND dla wszelkich niestandardowych flagami.

2. Define/redefine a toolset.

Dla CMake, rozważmy następujący wzór że ITK robi:

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

Answer 2

mam te same potrzeby, a ja w zasadzie dodaje wiersze poniżej zdefiniować własne wariant pokrycia w moim pliku 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 ; 

Dane pokrycia są tworzone, gdy test jest uruchamiany, a następnie wykorzystuję go poza bjam przy użyciu gcov.