静的解析および単体テストを実行するために、C++test は Wind River プロジェクトから次の情報を収集します。
- ソース ファイルへのパス
- コンパイル コマンドライン
- リンカー コマンドライン
この情報は、Wind River Workbbench プロジェクト構造の説明から取得され、自動生成 make ファイルをスキャンすることによって収集されます。スキャン プロセスは次のとおりです。
- C++test のテスト コンフィギュレーションを開きます。
- C++test プラグインは、テスト対象プロジェクトのビルド プロセスを内部的にアクティブにし、既存の make ファイルを強制的に再生成します。
- Workbench が make ファイルの再生成を開始すると、C++test プラグインはオプション スキャン ユーティリティを使ってコマンドラインを自動生成します。これはコンパイラ呼び出しの前に置くために使用されます。
- make ファイルが再生成されると、実際のビルド プロセスが開始します。make ファイルは、実際のコンパイル/リンカー コマンドラインではなく、オプション スキャン ユーティリティが前に置かれたコマンドラインを実行します。通常、コマンドラインは次のように変更されます。
- 元のコンパイル コマンドライン:
c++ppc <options> <file> - オプション スキャン ユーティリティが前に置かれたコンパイル コマンドライン:
options_scanner <options> c++ppc <options> <file>
- 元のコンパイル コマンドライン:
- オプション スキャン ユーティリティは、コマンドラインを解析して次のデータを保存します。このデータは今後も再利用されます。
- コンパイラ/リンカーの実行モジュール名
- コンパイラ/リンカーのオプション
- コンパイラの起動に使用される環境
ビルド プロセスが終了すると、C++test は収集された必要なすべてのデータを持ちます。
収集された C++test ユース モデルによって、Workbench プロジェクトを直接テストする場合もあれば、"テスト プロジェクト" を介してソースをテストする場合もあります。どちらの場合も、コンパイル/リンクの収集プロセスの背後にある概念は同じです。
重要な注意 - すべてのターゲットを強制的にビルドするには
一般的な make ユーティリティの動作に従って、特定ターゲットのコンパイル ルールは、実際にリビルドが必要であると make が判断した場合にだけ実行されます。たとえば、ソース ファイル test.c に最新のオブジェクト ファイル test.o がある場合、このファイルのコンパイル ルールは開始しません。 この動作は、C++test の解析時に実行されるオプションのスキャン プロセスに非常に影響します。つまり、現行ビルドおよびすべての最新バイナリ ファイルがあるプロジェクトに対して C++test の解析を実行した場合、make ファイルはコンパイル/リンク コマンドラインを実行しません。その結果、C++test は必要な情報を収集できません。
この問題を防ぐには、make ファイル コマンドラインに "-B" make フラグを追加して、強制的に無条件にすべてのターゲットをビルドします。
- プロジェクト ノードを右クリックし、ショートカット メニューの [プロパティ] をクリックします。
- [ビルド プロパティ] をクリックします。
- [Build Support and Specs] をクリックします。
- [Build command] フィールドで、make ファイル コマンドラインに -B フラグを追加します。たとえば：
%makeprefix% make -B --no-print-directory
この変更によって、C++test は、オプションの読み取りアクションが必要な場合にだけ、 必要な "-B" フラグで %makeprefix% を置き換えることができます。オリジナルのビルド プロセスは変わりません。この変更をプロジェクトごとに手動で行わずにすむように、make コマンドライン テンプレートのデフォルトを変更できます。詳細については 「C++test プラグインのための Wind River Workbench 環境の構成」を参照してください。
現在の環境において %makeprefix% マーカーを別の目的ですでに使用している場合、make コマンドラインのパターンに "-B" フラグをハード コーディングできます (%makeprefix% make -B -no-print-directory)。 ただし、この解決方法には大きな欠点があります。多くの場合、テスト セッションに対して "-B" フラグを追加し、製品ビルドのために削除するという変更を、コマンドライン テンプレートに対して定期的に行う必要があります。
状況に応じて、クリーン プロジェクトで解析を実行することができます。この場合、各テスト アクションの前にクリーン アクションを呼び出す必要があります。なぜなら、オプションのスキャンはプロジェクトのバイナリ ターゲットも生成するからです。
オプションのスキャンと解析が完了すると、C++test はプロジェクトの元の状態に何も挿入せずに、make ファイルを強制的に再生成します。
プロジェクトを確実に適切にリフレッシュするこの変更は、直接テストできる Wind River プロジェクトだけでなく、テスト プロジェクトに含まれるすべてのプロジェクトについても行うべきです。
Workbench 3.1-3.3 の既知の問題: Workbench ではプロジェクトの作成段階 (新規プロジェクトウィザード、[ビルド サポート] ページ) で [Build command] を設定できます。ただしバージョン 3.1-3.3 では、途中で [Build Specs] を設定した場合、新しいビルド コマンドは保持されません。プロジェクトのプロパティにはデフォルトのコマンドが表示されます。
重要な注意! － パースペクティブ
Wind River Workbench Application Development パースペクティブを使って C++test を使用することを推奨します。
Wind River Workbench Application Development パースペクティブでは、C++test または C/C++ CDT パースペクティブでは見えないリソースを選択できるほか、Wind River のビルド情報が古くなる問題を防止できます。
Workbench の起動後に最初に表示されたパースペクティブが C++test パースペクティブである場合、一部の内部ワークベンチ ビルド情報がロードされない現象が確認されています。その結果、make ファイルをスキャンしても目的のデータを収集できない場合があります。 その場合は、Workbench が内部データをロードするようにデフォルトの Application Development Workbench パースペクティブにスイッチして 、それから C++test パースペクティブに戻って解析を続ける方法を推奨します。この処理は、当該プロジェクトの Workbench を開始するたびに実行するべきです。また、新規にプロジェクトを作成するときに Application Development パースペクティブにいることを必ず確認するべきです。
