Ninja + CMakeの組み合わせがWindows上でも使えるように

CMakeの開発版ブランチ(next)と、Ninjaの対応ブランチ( https://github.com/syntheticpp/ninja/tree/ninja-for-cmake )でCMake + MSVCとMinGWのくみあわせが使えるようになった。このまま順調に行けば、CMake 2.8.9からすぐにWindows上でもNinjaが使えるようになるかもしれない。ちなみに、POSIX上でのNinjaはCMake 2.8.8以降で使用することができる。
Ninjaは非常に軽量なビルドツールで、makeのようなほかのビルドツールと違って、他のプログラムからビルドルールを出力することを想定している。Chromiumのために開発されたのでgypが唯一の生成元だったが、CMake 2.8.8からCMakeプロジェクトをNinjaでビルドできるようになっていた。
従来、CMakeプロジェクトをWindows上でビルドする場合はMSVCかjom、mingw32-makeのようなビルドツールが使われてきたが、これらのツールは異常に遅く、あまり実用的は言いがたい感じだった。
今回Ninjaをつかうことが出来るようになったことで、特にインクリメンタルビルドがかなり病的に高速化する。例えばLLVMのような比較的大規模なプロジェクトをビルドするなら、多くの場合NinjaとCMakeの組み合わせが最速になる。makeと比べてNinjaは再帰的でないので、２，３の巨大なビルドルールを読み込んでファイルを一気に走査するという方法を取ることが出来る。
もちろん、nmoshもCMakeを採用しているのでNinjaでビルドできる。というかNinjaでビルドできないともうビルドする気にならない。NinjaはLLVMとかChromium程度の規模のプロジェクトでもnullビルド(ファイルを一切変更していない場合のビルド)が数ms〜数秒で終わる。
Ninjaはビルドシステムのパラダイムを変える可能性があると思っている。Ninjaのビルドルール記述はパースしやすく簡潔なので、Ninja互換ビルドシステムを比較的簡単につくることができる。個人的には、LTOのようなWhole program analysisを既存の様々なソフトウェアプロジェクトに適用する実験をしていて、make互換のビルドシステムに近い成果を得ている。従来のこの手のプロジェクトは(Clangのstatic analyzerのように)C/C++コンパイラをwrapすることで実現されてきたが、Ninja互換のビルドシステムとすることで、プログラムのビルドフロー全体を使用してプログラムを変換/解析することが出来る。