|
統合開発環境Code::Blocksでビルド前後に外部ツールを自動実行するプレ/ポストビルドステップを説明する。
本サイトの利用する統合開発環境Code::Blocksは[Project|Build options]の[Project build options]ダイアログによりプロジェクトオプションとターゲットオプションの両方において[Pre/post build steps]ページ[Pre-buld steps]および[Post-build steps]複数行テキストボックスにより、実行ファイルのビルド前後に外部ツールを起動することができる。
外部ツールはToolsメニューからも起動できるが、ビルド時の自動処理を目的とする場合はこちらを利用する。
プレ/ポストビルドステップはアプリケーションを非表示で起動し、標準出力を[Logs & others|Code::Blocks]ウィンドウへリダイレクトし、ツールの終了を待つ。すなわちToolsメニュー外部起動の[Tools]メニューLaunch tool hidden with standard output redirectオプションとほぼ同じ動作で、デスクトップアプリケーションは新たなコマンドプロンプト(cmd /c)を介さないと表示起動できないのも同様である。一方でToolsメニューは単一ステップしか定義できないが、プレ/ポストビルドステップは複数ステップの定義ができる。ただし単一ステップでもcmd /cを介せば&演算子でコマンド連結できるので、これは大きなメリットとは言えない。逆にプレ/ポストビルドステップはワーキングディレクトリがプロジェクトディレクトリに固定されるが、これもcmd /c cd <directory> & <command>とすれば良い。
通常ターゲット(Debug32とする)のプレ/ビルドステップを含むビルド実行順は以下である。
複数ターゲットのプロジェクトでターゲット依存ビルドステップを定義する場合、組み込み変数$(TARGET_NAME)を用いてプロジェクトプレ/ビルドステップで共用化すればターゲット毎の定義を省略できると思うかもしれないが、これは避けた方が良い。二つのターゲット(Release32とRelease64とする)を持つバーチャルターゲット([Project|Properties]の[Project/targets options]ダイアログ[Build targets|Build targets|Virtual targets])のビルド実行順と$(TARGET_NAME)値は以下となり、プロジェクトプレ/ビルドステップに定義されるターゲット依存ビルドステップはあなたの意図と異なる結果を招く。
ターゲットレベルの自動処理はターゲットプレ/ポストビルドステップで行えば良いが、プロジェクトワイドな自動処理は悩ましい。例えば32ビット/64ビットアプリケーションをビルドして両対応インストーラを作成するDeployバーチャルターゲットを考えてみよう。
取り合えずこれで機能するが単一ターゲットビルドもプロジェクトプレ/ポストビルドステップを実行することを忘れている。アプリケーション開発は無数にデバッグビルドを繰り返すがその度にインストーラを作成されてはたまらない。そこでビルドは行わないがプレ/ポストビルドステップだけを行うターゲット(ダミーターゲット)として_DeployBeginと_DeployEndをDeployの最初と最後に追加する。
ダミーターゲットは[Project|Properties]の[Project/targets options]ダイアログ[Build targets]ページ[...|Build targets|Add]で作成し[...|Selected build target options|Type]でCommands onlyを選択する。[...|Selected build target options|Output filename]テキストボックスなどビルドに必要なパラメータの入力コントロールのほとんどが無効化される。[...|Selected build target options|Objects output dir]テキストボックスのみ有効のままだがその入力値が用いられることもなく恐らくバグであろう。Commands onlyターゲットに関するドキュメントは十分と言えないが、ビルドを要求しても実行せずプレ/ポストビルドステップのみ実行するターゲットとして使える。
しかしそのままではCommands onlyターゲットはいくつかの不具合を抱え以下の対応を必要とする。
Commands onlyターゲットを[Build|Build]などでビルドすると各ターゲットファイル毎にコンパイルが実行され多くの場合エラー終了する。一方でリンクはスキップされ問題とならない。[Build|Run]などでファイル実行を要求すると[Project|Set programs' arguments]の[Select target]ダイアログ[Host application]のホストアプリケーションを実行しようとする。コンパイルエラーを抑止するにはコンパイラ定義として*No Compiler*を選択するか、あるいは[...|Build target files]のチェックを全て外しターゲットファイルを持たせなければ良い。ただし後者は他のターゲット設定と大きく異なりメンテナンスを複雑化させるため推奨しない。
例として動作確認(1)のDesktop1プロジェクトにCommands onlyターゲット_Dummyを作成し、コンパイラ定義GNU GCC Compiler (32bit)で[Build|Build]する。
コンパイルは実行するが与えられたパラメータが不十分でエラー終了する。コンパイルをスキップさせるため*No Compiler*に変更する必要があるが、残念ながらそのままでは別のエラーが発生する
*No Compiler*の設定も変更する必要がある。
Commands onlyターゲットはポストビルドステップを2回実行する。リンクの代わりにポストビルドステップを実行するためだが恐らくバグで、ダミーターゲットはプレ/ポストビルドステップの区別に意味は無いのでプレビルドステップのみを用いれば済む。他に注意すべき点としてCommands onlyターゲットはターゲット出力を持たず$(TARGET_OUTPUT_FILE)や$(TARGET_OUTPUT_BASENAME)が空文字列となる事などが挙げられる。
*No Compiler*はデフォルトでインストールディレクトリに- No Compiler -、コンパイラなどの実行ファイル名全てに空文字列が設定されている。ビルド時のコンパイルはそのままでスキップするようになっているものの、ビルド前のコンパイラ定義妥当性チェックに引っかかりエラーとなる。チェックはC言語コンパイラ実行ファイルの存否によるのでこれをあらかじめ設定しておけば回避できる。[Settings|Compiler]の[Compiler settings]ダイアログ[Global compiler settings]ページ[...|Selected compiler]で*No Compiler*を選択し、例えば[...|Toolchaing executables|Compiler's installation directory]に$(#mingw32)、[...|Toolchaing executables|C compiler]にi686-w64-mingw32-gcc.exeを入力する。ファイル存否のみをチェックし実行する事は無いので実際はどんなファイルでも構わない。
これでDesktop1プロジェクト_Dummyターゲットを[Build|Build]すると意図通りターゲット毎にコンパイルがスキップされ、ようやくダミーターゲットとして機能する。