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も用意しておきたいと思います。

0 件のコメント:

コメントを投稿

注: コメントを投稿できるのは、このブログのメンバーだけです。

NetBSD/amd64でllama.cppを使ってみる

はじめに 生成AIが私の知りたいことに答えてくれたことはないのだが、手元の端末のみで動くのであれば、遊ぶのには良いかもしれない。 pkgsrcには含まれていないが、pkgsrc-wipには、llama.cppが含まれている。 llama.cppのうち、C++で書かれた部分は正...