インテル® Fortran コンパイラー XE 13.1 ユーザー・リファレンス・ガイド
ビルド処理を変更して新しいビルド構成を作成するのが難しい場合は、代わりにビルド仕様ファイルを作成しなければなりないことがあります。
ビルド仕様ファイルは、アプリケーションのビルド方法の詳細をまとめたものです。特に、スタティック解析を実行するのに必要なステップをまとめ、処理するファイルと使用するコンパイルオプションを指定します。また、解析結果とライブラリアンの呼び出しを生成するためにリンクしなければならない擬似オブジェクト・モジュールも示します。これらは、スタティック・リンク・ライブラリーに擬似オブジェクト・モジュールを結合するのに必要です。
インテル® コンパイラーでは、ビルド仕様を作成、実行するユーティリティー・プログラムが提供されています。これらのユーティリティーのいずれかを -help スイッチとともに起動して、使用方法に関するメッセージを表示するか、または -version スイッチでバージョンを識別してください。
ビルド仕様ファイルの作成
ビルド仕様ファイルを作成するには、いくつか方法があります。使いやすい順で次に説明します。
インジェクション・ユーティリティーは、ビルドコマンドを子プロセスとして起動し、プロセスの作成を遮断して、ビルド仕様ファイルを生成します。コンパイラー、ライブラリアン、リンカーの呼び出しがあるごとに、コマンドオプションをキャプチャーし、ビルド仕様ファイルに対応するコマンドを追加します。ユーティリティーは次のように実行します。
inspxe-inject -save-spec <output build spec> -- <build command>
次に例を示します。
inspxe-inject -save-spec buildapp_sca.spec -- make debug
インジェクション・ユーティリティーは自動でインテル® C++ コンパイラー、インテル® Fortran コンパイラー、Microsoft* Visual C++* コンパイラー、GNU* C++ コンパイラーの 4 つのコンパイラーを認識します。ビルド・プロシージャーが別のコンピューターでコンパイラー、ライブラリアン、リンカーを起動した場合は、インジェクション・ユーティリティーは正しく動作しません。
ビルドプロシージャーでアプリケーションの一部ではないファイルをコンパイルまたはリンクする場合、作成されたビルド仕様ファイルでもこれらのファイルを解析します。ビルド中に関連していないソースファイルのコンパイルが避けられない場合は、テキストエディターでビルド仕様ファイルを編集して不要なコンパイルステップとリンクステップを排除してください。
コンパイル、ライブラリアン、リンカーステップをそれぞれ "ラップ" するようビルドプロシージャーを変更して、それから変更したビルドを実行します。
ラッパー・ユーティリティーは、ビルド仕様ファイルの作成を直接制御するための手段を提供します。ラッパー・ユーティリティーを起動するたびに、ラッパー・ユーティリティーはビルド仕様ファイルに 1 行追加します。ラッパー・ユーティリティーへの引数としてコマンドラインを指定すると、ラッパー・ユーティリティーは対応する行をビルド仕様に追加します。そして、オプションでコマンドを実行します。
ある意味ラッパー・ユーティリティーは、ビルド処理の収集方法を除き、インジェクション・ユーティリティーと似ていると言えます。インジェクション・ユーティリティーは、ビルドスクリプトのサブプロセスとして呼び出される処理を監視します。ラッパー・ユーティリティーは、コマンドライン引数で監視するように指定された処理を監視します。監視対象の処理は実際に発生したり、しなかったりします。
最も基本的なアプローチは、ビルドスクリプトを変更し、各コンパイラー、ライブラリアン、リンカーコマンドをラッパーを呼び出す対応するコマンドに置換することです。(ディレクトリーの変更やファイルのコピーなどの追加のコマンドもキャプチャーしなければならないことがあります。) 例えば、-no-run オプションが指定されない場合、ラップされたコマンドの実行はコマンド自体をそのまま実行します。 つまり、この変更はビルドスクリプトを中断しません。ただし、ビルドスクリプトを実行することで、その副産物としてビルド仕様が作成されます。このアプローチは、makefile、シェルスクリプト、ant スクリプトなど、どのスクリプト言語でも使用できます。
この基本的なアプローチを変更する方法は 2 つあります。1 つ目は、特定のコマンドをラップしないように選択することです。これにより、ビルド仕様から特定の処理を除外することができます。2 つ目は、(-no-run オプションを使用して) 追加でラッパーを呼び出し、そうでなければキャプチャーされない特定のコマンドをビルド仕様に追加することです。 いくつかの例について考えてみましょう。
リモートマシンでコマンドを呼び出すため、remote_shell というユーティリティー・プログラムをビルドで使用しているとします。 インジェクション・ユーティリティーは、このような方法で実行される処理を監視できません。ユーティリティーへの第 1 引数はリモートマシン名、その他の引数はリモートで実行されるコマンドの場合、ビルドスクリプトには次のような行が含まれます。
remote_shell host1 gcc <args> file1.c
次のような行を追加できます。
inspxe-wrap -no-run -save-spec buildapp_sca.spec -- gcc <args> file1.c remote_shell host1 gcc <args> file1.c
この追加行は、file1.c が指定された引数でコンパイルされることを記録するようにラッパー・ユーティリティーに指示します。 -no-run オプションは、inspxe-wrap に gcc を呼び出さないように指示します。 オリジナルのコマンドは変更されず (アンラップされ)、通常通りに実行されます。remote_shell コマンド自体をラップしても、ラッパー・ユーティリティーは remote_shell コマンドをコンパイラーの呼び出しと認識できません。 この手法は、ラッパー・ユーティリティーによって認識されない任意のコマンドを変換するのに使用できます。認識される形式 (この場合は gcc* の呼び出し) をラップするラッパーの呼び出しを追加するだけです。
場合によっては、ビルドスクリプトはユーティリティー・プログラムをビルドし、そのユーティリティーを実行して、後で実際のアプリケーションにコンパイルされるソースファイルを生成することがあります。(ユーティリティー・プログラムは実際の製品の一部ではないので) ユーティリティー・プログラムに対してスタティック解析を実行してもあまり意味がありません。ユーティリティー・プログラムのビルドステップで特定のラッパーの呼び出しを省略することで、ビルド仕様ファイルからユーティリティー・プログラムを効率良く除外することができます。
最も困難なケースは、アプリケーションが、実行するコマンドをテキスト形式で表明しない不明瞭なプログラムによってビルドされる場合でしょう。この場合、ラップできるコマンドはありません。しかし、実行されたコマンドとオプションのログをキャプチャーできることがあります。そして、テキストエディターを使って、そのログを実行時に再度ビルドを行う一連のコマンドに変換します。各コマンドをラッパーの呼び出しに置換することで、実行時にビルド仕様を生成するスクリプトを作成できます。
構文:
inspxe-wrap -save-spec <output build spec> [-no-run] -- <command>
次に例を示します。
inspxe-wrap -save-spec buildapp_sca.spec -- icl $(CFLAGS) file1.c
インストルメント済みのビルドで作成された処理は、ビルド仕様の以前の内容に追加されます。そのため、変更されたビルドを実行する前に、ビルド仕様ファイルの出力を削除しなければなりません。
複数のプロジェクト、複数の構成、共有コードの処理について
1 つのマスター・ビルドスクリプトを使用して、複数のプロジェクトや同一プロジェクトの複数の構成をビルドすることがあるかもしれません。例えば、1 つのビルドスクリプトで、複数のアプリケーションのデバッグおよびリリースバージョンをコンパイルしリンクします。
インジェクション・ユーティリティーで (またはラッパー・ユーティリティーによるインストルメンテーション後) このようなビルドスクリプトを実行すると、ビルドされたすべてを実行時にスキャンする 1 つのビルド仕様ファイルが生成されます。これは、1 つのプロジェクトだけをスキャンできないので不便です。また、同一プロジェクトのすべての構成ファイルには通常、同じ問題があるため、同じプログラムの複数の構成ファイルをスキャンすることは役に立たないかもしれません。
マスター・ビルドスクリプトが、1 つのプロジェクトの 1 つの構成のみビルドすることができれば、それを使用して各プロジェクトごとに別々のビルド仕様ファイルを作成すると良いでしょう。これにより、個々のプロジェクトをスキャンすることができます。その後、すべてのプロジェクトをスキャンするスクリプトを記述することができます。
ただし、共通のソースファイルやライブラリーが複数のプロジェクトにビルドされることがあります。このような場合、解析結果に大きな重複が生じます。つまり、共有ファイルにある問題が、それを使用する各プロジェクトに現れることになります。共有ファイルの問題は、一部のプロジェクト・コンテキストで検出され、ほかでは検出されない可能性もあります。この可能性をカバーするために、各プロジェクトの該当するファイルの結果を解析すると良いでしょう。これを行う価値があるかどうかは、開発者自身が決定する必要があります。
1 つのプライマリー・プロジェクトを選択して、共有ファイルの解析結果を調査することもできます。(ライブラリーについては、ライブラリー自身の解析結果を調査するのが良いでしょう。) また、プライマリー・プロジェクトの解析結果と別のプロジェクトの調査結果を比較して、共有ファイルで新しい問題が発見されたかどうかを確認することもできます。
ビルド仕様ファイルの使用
ビルド仕様ファイルを作成したら、スタティック解析の実行に使用できます。ビルド仕様は、プロジェクトからファイルが追加または削除されるごとに、またはコンパイルオプションが変更されたときには必ず更新してください。更新を怠った場合は、アプリケーション全体のフルの解析が行われません。
ビルド仕様からスタティック解析を実行するには、次のコマンドライン・ユーティリティーを使用します。
inspxe-runsc -spec-file <build spec> [<options>]
<options> は、コンパイル (およびリンク) ステップに渡される追加オプションを表します。
ビルド仕様ユーティリティー・オプション
オプション | 結果 |
---|---|
-?、-h、-help |
コマンドライン・オプションの説明を表示します。 |
-d-i=id -disable-id=id |
指定した id の警告を無効にします。 |
-e-i=id 、-enable-id=id |
指定した id の警告を有効にします。 |
-l=(1 | 2 | 3)、-level=(1 | 2 | 3) |
スタティック解析のレベルを指定します (デフォルト = 3)。 |
-l-d=dir、-log-dir=dir |
情報が記録されるディレクトリーを指定します。 |
-no-return-app-exitcode |
結果ではなく、ツールの成功に基づいてリターンコードをセットします (inspxe-inject のデフォルト)。 |
-o-i=file、-option-file=file |
コマンドライン・オプションを含むファイルを指定します。 |
-q、-quiet |
不要なメッセージを表示しないようにします。 |
-r=dir、-result-dir=dir |
解析結果が作成されるディレクトリーを指定します (inspxe-runsc のみ)。 |
-return-app-exitcode |
ツールではなく、操作の成功に基づいてリターンコードをセットします (inspxe-wrap および inspxe-runsc のデフォルト) |
-s-s=file、-save-spec=file |
ビルド仕様を含むファイルを指定します (inspxe-wrap および inspxe-inject のみ)。ラッパー・ユーティリティーはこのファイルに追加します。インジェクション・ユーティリティーはこのファイルを上書きします。 |
-t-d=dir、-tmp-dir=dir |
一時ファイルが作成されるディレクトリーを指定します。 |
-v、-verbose |
追加情報を出力します。 |
-V、-version |
ユーティリティーのバージョン番号を表示します。 |
ユーザーの使用法によるエラー (無効なコマンドライン・オプションなど) では、リターンコード 1 が返されます。ツール側のエラーでは、リターンコード 2 が返されます。さらに、次の規則が適用されます。
inspxe-inject コマンドラインに -return-app-exitcode を追加すると、inspxe-inject ユーティリティーは観測されたビルドコマンドのリターンコードを返します。これは、ビルドコマンドのリターンコードが、ビルド仕様ファイルで記録された処理が正しく完了したかどうかを示す信頼性の高いものである場合、推奨されます。
オプションが指定されない場合は、デフォルトでレベル 3 スタティック解析を行うオプションが追加されます。