Bjam для анализа покрытия gcov?

Я ищу интеграцию нетривиальной кросс-платформенной системы сборки для проекта, преимущественно написанного на C++. До сих пор я оценивал Cmake и Scons, и, хотя они оба представляют собой улучшение по сравнению с (GNU) make, ни один из подходов не казался ни элегантным, ни прозрачным в контексте я пытался использовать эти инструменты. Это привело меня к Boost Build (Bjam), и я воодушевлен тем, что, учитывая, что мой проект зависит от Boost, bjam должен быть доступен для любой жизнеспособной целевой платформы. уже.

Я столкнулся с трудностями, пытаясь аккуратно интегрировать покрытие кода для модульных тестов библиотеки...с целью возможной интеграции в сервер сборки, такой как Jenkins. Хотя я готов руководствоваться передовой/стандартной практикой Bjam, я думаю, что мне нужны три различных «варианта»:

• выпуск — для создания только оптимизированной статической библиотеки
• отладка — для создания неоптимизированной статической библиотеки и модуля тесты
• покрытие — для создания библиотеки с поддержкой покрытия и связи с модульными тестами без покрытия.

По существу, помимо стандартных отладочных и выпускных сборок, мне нужна специальная отладочная сборка, которая также собирает данные о покрытии.

Мне нужно собрать (как минимум) g++ и msvc... и использовать переключатели gcov только с g++. Это означает, что моей цели библиотеки нужны разные «флаги компилятора» для исполняемой цели модульного теста... и только для одного из моих наборов компиляторов... и только для одного варианта.

Мне неясно, как лучше всего добиться этого с помощью Bjam, хотя я подозреваю, что это должен быть довольно распространенный вариант использования. Имеет ли Bjam явную поддержку анализа покрытия gcov (возможно, представление результатов используя lcov)? Если нет, может ли кто-нибудь порекомендовать стратегию, которая поддерживала бы описанный выше (упрощенный) сценарий?