Diary: NetBSDで最新のMozcを使う 2

この記事は、NetBSD Advent Calendar 2023の20日目の記事です。

昨日に続き、Mozc 2.29.5268.102をNetBSD/amd64で使うまでの話を書きたいと思います。ここで、NetBSD/amd64と書きました。昨日は書き忘れてしまいましたが、Bazelは64ビットの環境でしかビルドできません。ですので、NetBSD/i386に代表される32ビットの環境ではBazelが動かないので、 Mozc 2.29.5268.102をビルドすることはできません。残念です。

ちなみに、以前のMozcよりOSに依存するコードは格段に少なくなっているようです。そういう部分はabseil-cppを利用することになったのかもしれません。 Bazelが良いためでないのは間違いありませんが…。

mozc-serverのビルド

Mozcのパッケージは、pkgsrc/inputmethod/mozc-serverからビルドしていくことになります。実を言いますと、mozc-serverのビルドは難しくありませんでした。潜在的なBazelの問題は、mozc-serverのビルドでは表面化しなかったのです。

ですが、以下のようにすれば、pkgsrc開発者的にはうれしいような気がします。

do-build:
        cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
                ${PREFIX}/bin/bazel \
                        --output_user_root=${WRKDIR}/bazel \
                        --client_debug \
                        build \
                        server:mozc_server \
                        --host_action_env=CWRAPPERS_CONFIG_DIR=${CWRAPPERS_CONFIG_DIR} \
                        --action_env=CWRAPPERS_CONFIG_DIR=${CWRAPPERS_CONFIG_DIR} \
                        --host_action_env=PATH=${PATH} \
                        --action_env=PATH=${PATH} \
                        --sandbox_debug \
                        --verbose_failures \
                        --subcommands \
                        --config oss_linux --compilation_mode opt

ここで、--output_user_rootをWRKSRC以下に設定すれば、make cleanすることでビルドの過程で生成されたものは全て削除することができます。また、--subcommandsを指定することで、どのようなコマンドが実行されたのか表示されるようになります。ここで、oss_linuxというconfigを指定しているのですが、特にLinuxに特化したものではなく、 Unix-like OS全般に適用できるものでしたので、このままで大丈夫です。 --host_action_envや--action_envでcwrapperの変数を渡していますが、これは本当は不要でしょう。 Bazelはサンドボックス機能を持っているので、明示的に渡さないと環境変数も暗黙の内には引き継がれません。

これで、WRKSRC/bazel/bazel-out/netbsd-opt/bin/server/mozc_serverが生成できました。

mozc-rendererのビルド

次にはpkgsrc/inputmethod/mozc-rendererをビルドします。 pkgsrc以外のパッケージ管理の仕組みでは、mozc-rendererを個別のパッケージにしていない場合もあるようですが、pkgsrcでは分けています。この方が依存関係を解決するには良いと思うのですが…。

現在のMozcのmozc-rendererはQt6を利用しています。 Bazelではソースファイル(.cや.cxxなど)に加えて、そこからインクルードされるヘッダーファイルまでBazelファイル中で再帰的に依存関係として記載しておく必要があります。個人的には、そんな必要があるような気がしないのですが…。しかもBazelファイルを記述するドメイン固有言語であるStarlarkではdir/**というそのディレクトリー以下のファイルを再帰的に指定する方法も提供されていますので、自己否定しているような気もしてしまいます…。

いずれにしても、Qt6のようにツリー外の依存関係を解決するのは、Bazelでは少し面倒ですし、一級市民ではないようです。 pkg-configの結果から、依存関係を自動生成する仕組みがMozc用に用意されていました。ですが、少なくともNetBSD/amd64上のpkgsrcにとっては、指定されたパッケージでは不足していました。WORKSPACE.bazelで、Qt6OpenGLとglもpkg-configで情報を取得する対象にする必要がありました。

ここまでは、よくあることなのですが、実際にビルドしてみると、Qt6のヘッダーファイルが不正に利用されているとしてBazelがエラーを多量に発生させてしまいます。どうやら、cc -MDで生成される.dファイルの内容と、Bazelのサンドボックス機能で作られたヘッダーファイルのパスが一致しているかをチェックしているようです。例えば、/usr/pkg/qt6/include/QtCore/QObjectが不正に利用されているとエラーが発生していました。

いろいろと試してみると、2つのことが分かりました。 1つ目は、そもそも/usr/pkg/qt6という絶対パスはBazelファイルでの依存関係として指定されていないと言うこと、2つ目は依存関係に絶対パスを指定するとBazelは絶対パスの指定を許さずエラーになると言うことです。

Bazelは、ヘッダーファイルのパスを指定するのに、-Iではなく-isystemを利用します。そして、各ヘッダーファイルは、シンボリックリンクでWRKSRC/bazel以下にBazelが配置します。 NetBSD/amd64-currentのGCC 10.5.0は、-isystemで絶対パスを設定し、それがシンボリックリンクを含んでいる場合に、シンボリックリンクをたどった結果のパスを.dファイルに記載するような挙動になっていました。clangはそうではありません。

ここまで、NetBSD baseのccを使ってビルドするようにbazelをブートストラップしていたのですが、 GCCの挙動ではBazelは気にいらないようです。 pkgsrc/lang/clangからインストールされるclang/clang++を使うようにすることにしました。これで正常にビルドは完了するようになりました。

mozc-tool、fcits5-mozcのビルド

mozc-rendererがビルドできれば、mozc-toolもfcitx5-mozcも問題なくビルドすることができました。

今後について

Mozc自体はibus用のモジュールをビルドするようになっています。私がfcitx5を利用しているので、今のところibus-mozcまでたどりついていませんが、 commitするまでには、ibus-mozcも用意しておきたいと思います。

Diary

NetBSDで最新のMozcを使う 2

mozc-serverのビルド

mozc-rendererのビルド

mozc-tool、fcits5-mozcのビルド

今後について

0 件のコメント:

コメントを投稿

plgarc/wip/llama.cppでpkgsrcのBLASサポートを探る

不正行為を報告

ラベル