Tools to build Google Chrome, gyp and Ninja
先日から yamake というオレオレメイクツールを作っている*1のですが、その直後のとあるツイートで gyp、Ninja というビルドシステムがあるということを知りました。どちらも、Chromium のビルドをより良くするために生まれたようです。知らなかったので、少し調べてみました。
Google がこういったビルドツールの開発に積極的な理由
Google Chrome というブラウザがクロスプラットフォームなブラウザだからだと思います。詳細は、gyp のドキュメントに書かれています。
特に厄介なのが Mac OS X での開発だそうで、Xcode を必ず通さないといけないようです。なので、まずはそれにパスすることを目標とし、それに併せて他を揃えていったらしいです。
gyp
以下の動画が分かりやすいと思います。
gyp 自体はビルドツールではなく、ビルドするための何らかのファイルを生成するビルド補助ツールです。*2ドキュメントとソースコードをチラ見した限りでは、以下のような特徴があるように思えました。
- 記法は JSON 形式っぽいもの
- Visual Studio、Xcode、SCons、Autotools に対応している
- Python で実装されている
依存性解決などはそれぞれの環境でそれなりのものがあるので、中継部分だけを作るという考え方には非常に共感できますが、記法が少しまどろっこしい気がします。ドキュメントにあったサンプル*3を抜粋します。
{ 'target_defaults': { 'defines': [ 'U_STATIC_IMPLEMENTATION', ['LOGFILE', 'foo.log',], ], 'include_dirs': [ '..', ], }, 'targets': [ { 'target_name': 'foo', 'type': 'static_library', 'sources': [ 'foo/src/foo.cc', 'foo/src/foo_main.cc', ], 'include_dirs': [ 'foo', 'foo/include', ], 'conditions': [ [ 'OS==mac', { 'sources': [ 'platform_test_mac.mm' ] } ] ], 'direct_dependent_settings': { 'defines': [ 'UNIT_TEST', ], 'include_dirs': [ 'foo', 'foo/include', ], }, }, ], }
Makefile に比べると、記述すべきことがかなり絞られていることがよく分かります。SCons を使っていたときに思ったのですが、私は文字列を引用符で括ったり、何か記号が多いのは嫌いです。*4
Ninja
少し前に SourceForge.JP からニュースが出ています。
こっちの記事が元ネタですかね。
ドキュメントとソースコードをチラ見した限りでは、以下のような特徴があるように思えました。
- 「とにかく速く」という哲学を持っている
- 記法は make と似ている
- C++ で実装されている
- 並列ビルドに対応しているっぽい
- Visual Studio などを使ったビルドをするには一手間必要になりそう
ドキュメントにあったサンプルを抜粋します。ノリは make に近いと思います。
cflags = -Wall rule cc command = gcc $cflags -c $in -o $out build foo.o: cc foo.c
もう少し調べておきたいこと
自分で書いたコードのビルドはどうにでもできるのですが、何らかのライブラリを利用している場合、そのビルドを取り込む必要があります。大抵のオープンソースプロジェクトでは基本的に Autotools で configure、make するためのファイルが提供されています。しかし、Windows や Mac OS X などに向けたものはなかったり、あったとしても用意されているものの形式はばらつきがあります。Google Chrome ではこれらをどうやって統合しているのでしょうか。というあたりを次回あたりで書いてみようと思います。
*1:yamake is makefile generator from YAML
*2:yamake は Ninja よりも gyp に近いです
*3:GypUserDocumentation - gyp - Project Hosting on Google Code
*4:日本語キーボードでは記号を打つのは面倒ですよね
state and status
プログラミングをしていると、状態管理をすることがよくあります。私がよく迷うのは、state、status の使い分け方です。
私の理解では、state = one of status です。例えば、HTTP レスポンスの最初の一行目*1には status code というものがありますが、これは決して state code ではありません。あえていうなら 200 とか 404 とか 500 とかいうものが state code です。
ですので、以下のように使い分けています。
- status
- 状態の型
- 状態変数名
- state
- 状態型が列挙型である場合、そのひとつひとつの定義に用いる
- getter/setter の関数名 ( ex. getState, setState )
で、実際どうなっているのか少し調べただけでも結構ばらつきがありました。厄介ですね。
というわけで、状態の型として state を使うか status を使うかは微妙です。が、割と意味は通じるのでどっちでもいいよ、という説もあります。
*1:通称 status line