New configuration system

by Tasuku Suzuki · 公開済み 2016/08/20 · 更新済み 2019/06/11

この記事は、2016年6月23日に Qt の Developer メーリングリストに投稿された New configuration system というメールを適当に訳したものです。

やぁ、

すでに知っている人もいるかもしれないけれど、最近俺は Qt の新しい configuration システムを開発してるんだ。一番最初の大きな変更が昨晩マージされたから、このタイミングでその変更と今後の予定について説明するよ。

新しいシステムのゴールは２つ。

１つめは、Qt のビルドのカスタマイズについての要望が、特に組み込み系のユーザーから非常にあがっているんだ。多くの場合は容量に関する制限で、Qt から製品開発に必要のない機能を外すことができないか？って話。昔はそういう仕組みが Qt にあったんだけど（詳しくは src/corelib/global/qfeatures.txt を見てね）configure スクリプトには完全には組み込まれていなくて、Qt 4 の時代からそんなにちゃんとメンテナンスされてなかったし、いろんな制限があったんだよね。この仕組みを新しいシステムでそれを改善できたらなぁと思ってる。

２つめは、長い間、２つの別々の configure システムがあったこと。Unix 向けのモンスターのようなシェルスクリプトと、Windows 専用の Qt で作ったやつ。Qt の設定まわりを変更しようとするとだいたいその両方を変更する必要があって、へんなバグの温床になってたんだよね。メンテナンスのしやすさは結構ひどい感じだった。

というわけで、新しいシステムを作ることにしたんだ。最初に言ったように、最初の（でもでかい）パッチ（https://codereview.qt-project.org/#/c/149202/）が昨晩マージされた。これは設定の定義をシェルスクリプトの中から（configure.json という名前の）json ファイルに持っていくもので、qmake にこの json の処理をさせる予定。今の段階では Unix のみが対象で、Windows はもうしばらくは configure.exe が使われるよ。この変更では古いシェルスクリプトと新しいシステムで（可能な限り）同じ設定になっているはずなので、もし今までどおり configure を動かして、動かなくなっていたら俺に教えてね。

新しいシステムの詳細についてはもう一個別のメールを送るので、興味がある人は読んでほしい。

それぞれのモジュールに qtmoduleglobal.h と qtmoduleglobal_p.h を追加

Qt のほとんどのモジュールには専用の global なヘッダファイルがあって、クラスやシンボルの export/import のハンドリングのために使っているんだけど、新しいシステムではモジュールごとにパブリックな global ファイルと private な global ファイルを持つようにするよ。すべてのパブリックなヘッダ＝ファイルはパブリックな global ファイルを include するようにして、そのあとでプライベートの方も同じようにする予定。

これは設定システムのモジュール化のためと、依存している特定の機能が有効かどうかをちゃんと判別できるようにするために必要なんだ。

というわけで、https://codereview.qt-project.org/#/c/161143 とそれに続く変更（global_p.h の追加の変更が今はないけど間もなく追加する予定ね）をチェックしてみて。

サードパーティーのライブラリのハンドリングを改善

いまは外部のライブラリの依存関係は pro ファイルの中で結構適当に処理されているので、それもやり方を統一する予定。https://codereview.qt-project.org/#/c/161660/ を見てみてね。

新しい configure システムのモジュール対応

新しいシステムが各モジュールでもちゃんと動くようなパッチもいくつか書いていて、基本的にはモジュール（ライブラリ）ごとに１つの json ファイルを用意して、この新しいシステムで qtbase 以外のリポジトリにもちゃんと対応できるようになる予定。今のシステムは色々制限が多い。

この変更を受けて qtmodule-config.h と qtmodule-config_p.h とそれに対応する .pri ファイルをそれぞれのモジュールに追加する予定。qtmodule-config.h はモジュールの global なヘッダファイルが include して、プライベートの方も同じようにする。

パブリックの pro ファイルにはモジュールが外部に公開する機能の一覧の定義みたいのを追加して、プライベートな方にはモジュール内でのみ有効な機能の一覧を保持する予定。たとえば、’mimetypes’ は QtCore のパブリックな機能（これを切り替えると一部の API が変更になる）なのに対して、’glib’ はかなりプライベートな機能（単に内部で使用するイベントループを変更をするだけで、API は変更しない）という感じ。

具体的には https://codereview.qt-project.org/#/c/159604/40 とそれに続く変更を見てください。

古い feature システムの統合

以上の変更が終わったあとで、最初に言った昔からあった feature システムというのをこの新しいシステムに統合する予定。ここまでくるとこの作業はわりと簡単（https://codereview.qt-project.org/#/c/159763/）。

そして、さらにヘッダーファイルとソースファイルで機能の有無を処理する新しいメカニズムを導入する予定。いまの #ifndef QT_NO_FOO は 二重否定 になっているので読みづらいし安全じゃない。安全じゃないっていうのは、’foo’ という機能が（typo やその機能が wiigets モジュールで定義されているにも関わらずそのモジュールを使っていないなどで）無効な場合、コンパイラがエラーを出したり警告を出してくれないということ。とりあえず “#if QT_HAS_FEATURE(foo)” というマクロを使うようにして、foo が既知の機能じゃない場合にはエラーになるようなパッチをいくつか書いているところ。これで素敵なことに .pro と c++ のファイルで同じ名前になるような感じにできそう。

シェルスクリプトのさらなる削減

長期的なゴールはシェルスクリプトの割合をさらに減らすことで、qmake のためのブートストラップとしてまでもっていって、それ以上の機能はすべて qmake に任せたい。まだいくつもプッシュしていないパッチがあるんだけど、今日からでも手伝ってくれたら本当にありがたい。

configure.exe の削除

最終的には、もちろん configure.exe を廃止して、Windows でも同じように（現在 configure.exe を作成しているような感じで最低限の qmake 用のブートストラップを用意して）、qmake がほとんどの処理をするところまで持っていけたらいいね。これが全部できたら、唯一のクロスプラットフォームの configure システムの完成だ。で、これについてはボランティアを絶賛募集中ね！ｗ