ある程度規模の大きい C/C++ のプロジェクトの頭痛の種のひとつがビルドだ。ソースコードから実行ファイルやライブラリを作るするだけなのに、なぜかやたら複雑になりがちだ。気づくとビルドのトラブルで何時間も費やしていたりする。どうしてこうもややこしいのだろうか？
一番物事をややこしくするのはクロスプラットフォームの対応だろう。Windows, Mac, Linux など各種のプラットフォームに対応したプロジェクトでは、ビルドの複雑さはとんでもないことになる。プラットフォームによって、コンパイラの種類も違えば、使えるライブラリも違う。あらゆる流儀が少しづつ異なるのだ。
デバッグビルドとリリースビルドで最適化のオプションを変えたり、オープンソース版と製品版でアイコンを切り替えたりなど、ビルドのコンフィグレーションが何通りもあることも複雑性を増大させる。やり方が何通りもあると、ちょっといじっただけで何かが壊れたりするものだ。
この他にも、コード生成やら（ソースコードから実行ファイルを作って、それでコード生成してさらに先に進むとか）、依存解析やら、クロスコンパイルやら、ビルドをややこしくする要因は無数にある。
これらの問題をすべてきれいに解決するビルドツールは私が知る限り存在しない。よって、どのツールを使っても何かしら不満は溜まるものだ。
個人的に一番悪い思い出があるビルドツールは autoconf だ。autoconf は libfooは存在するか? strdup関数は存在するか？などとビルド環境の検証を行うツールだ。が、この検証を行うためのルールを書くのが至難の業なのだ。大体、いまどきstrdupが存在しないプラットフォームに対応する暇があったら、他のことに労力を使ったほうがいい。
SCons を一時期使ってみたが、印象はよくない。ビルドファイルというものは基本的に宣言的に書きたいものだが、SConsではビルドファイルの中でPythonで何でも書けてしまうので、ついロジックをたくさん書いてしまうのだ。これをやってしまうと、見通しは悪くなるし、ものすごい勢いで複雑性が増大する。
今まで使った中で一番ましなビルドツールが GYP[1] だ。JSON的なフォーマットでビルドファイルを書くと、プラットフォームごとに Makefile, .xcodeproj, .vcproj などのファイルを生成してくれる。ルールは基本的に宣言的で、変数に基づいたif文だけが認められている。
GYP は Chromium [2] という大規模かつクロスプラットフォームなプロジェクトで使われていて、今のところ、なんとか持ちこたえている。メジャーなツールではないけど、結構頼りになるやつだと思う。
ちなみに、Chromium のすべてのGYPファイルを合計すると、ほぼ10万行に達する。
[1] http://code.google.com/p/gyp/
[2] http://www.chromium.org/