6

主に C++ で記述されたプロジェクトに、重要なクロスプラットフォーム ビルド システムを統合しようとしています。私はこれまで Cmake と Scons を評価してきましたが、どちらも (GNU) make よりも改善されていますが、私がこれらのツールを使用しようとしていたコンテキストでは、どちらのアプローチもエレガントでも透過的でもないように見えました。これにより、Boost Build (Bjam) にたどり着きました。私のプロジェクトが Boost に依存していることを考えると、bjam は実行可能なターゲット プラットフォームで既に利用できるはずです。

Jenkins などのビルド サーバーへの最終的な統合を視野に入れて、ライブラリの単体テスト用のコード カバレッジをきちんと統合しようとするのが困難になりました。私は Bjam のベスト/スタンダード プラクティスに進んで従いますが、3 つの異なる「バリエーション」が必要だと思います。

  • release - 最適化された静的ライブラリのみをビルドする
  • debug - 最適化されていない静的ライブラリと単体テストをビルドする
  • カバレッジ - カバレッジ対応のライブラリを構築し、カバレッジ対応でない単体テストとリンクします。

基本的に、標準のデバッグ ビルドとリリース ビルドに加えて、カバレッジ データも収集する特別な目的のデバッグ ビルドが必要です。

(少なくとも) g++ と msvc でビルドする必要があり、gcov スイッチは g++ でのみ使用します。これは、私のライブラリ ターゲットが単体テストの実行可能ターゲットとは異なる "compilerflags" を必要とすることを意味します...そして、私のコンパイラ スイートの 1 つに対してのみ...そして 1 つのバリアントに対してのみです。

Bjam でこれを実現する最善の方法はわかりませんが、かなり一般的な使用例であると思います。Bjam は gcov カバレッジ分析 (おそらく lcov を使用して結果を提示する) を明示的にサポートしていますか? そうでない場合、上記の（単純化された）シナリオをサポートする戦略を誰かが推奨できますか?

4

2 に答える 2

1

あなたの最初の質問 (bjam が gcov を明示的にサポートしているかどうか) に対する答えは、間違いなくnoであると確信しています。なぜなら、デバッグおよびリリース ビルド構成と同様に、bjam はそれをユーザーが定義する機能バリアントであると見なすからです。 .

bjam の場合、必要なことを行うにはいくつかの方法があるようです。

  1. 独自の機能バリアントを定義してから、カスタム フラグの CONFIG_COMMAND を更新します。

  2. ツールセットを定義/再定義します。

CMake の場合、ITK が行うパターンに従うことを検討してください。

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

于 2012-05-27T00:59:22.547 に答える
1

私も同じニーズを持っており、基本的に以下の行を追加して、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 ;

カバレッジ データはテストの実行時に作成され、後で bjam の外で gcov を使用して活用します。

于 2015-01-06T15:12:45.297 に答える