前へ 次へ
Mozilla では XPCOM のインタフェースを IDL を使って記述している。 もちろん DOM オブジェクトのインタフェースも IDL で記述されており、ビルド時に IDL から自動的に C++ 用ヘッダファイル (nsIFooBar.h のような) などが生成されていたりする。
さて mozilla-central では、先日これら IDL の位置が変更された。例えば、<canvas> 要素 の 2d コンテクスト (CanvasRenderingContext2D) の IDL は以下のように動かされた。
dom/public/idl/ が dom/interfaces/ に変っただけである。
しかし話はこれで終りではなく、今後もソースツリーの構成は変るようだ。
DOM について言えば、実装 (nsFooBar.(h|cpp) など) も現在の位置から動かされるようだ。現在は content/ と dom/src/ に別れているファルを dom/ 以下にまとめられる。 一貫性が増してわかりやすくなる反面、リンク切れが頻発すると思われるので、これらのファイルを参照するときは注意が必要だろう。
もっとも mxr では、あるファイルが違うディレクトリに移動していても簡単に見つけることができる。
詳細検索
random Hatena Ring svg
random Hatena Ring firefox
random Hatena Ring pblog
Mozilla では XPCOM のインタフェースを IDL を使って記述している。 もちろん DOM オブジェクトのインタフェースも IDL で記述されており、ビルド時に IDL から自動的に C++ 用ヘッダファイル (nsIFooBar.h のような) などが生成されていたりする。
さて mozilla-central では、先日これら IDL の位置が変更された。例えば、<canvas> 要素 の 2d コンテクスト (CanvasRenderingContext2D) の IDL は以下のように動かされた。
dom/public/idl/ が dom/interfaces/ に変っただけである。
しかし話はこれで終りではなく、今後もソースツリーの構成は変るようだ。
DOM について言えば、実装 (nsFooBar.(h|cpp) など) も現在の位置から動かされるようだ。現在は content/ と dom/src/ に別れているファルを dom/ 以下にまとめられる。 一貫性が増してわかりやすくなる反面、リンク切れが頻発すると思われるので、これらのファイルを参照するときは注意が必要だろう。
もっとも mxr では、あるファイルが違うディレクトリに移動していても簡単に見つけることができる。