mozcをコンテナでビルドする

mozcにユーザー辞書を入れたい mozcはgoogle日本語入力のオープンソース版 しかし辞書は入っていないので、最小限の辞書のみを入れている 知らないことはたくさんある。 そもそも、キーボードの入力の列からローマ字やひらがなに変換し、それをいくつかの節に分割して、候補となる変換先を列挙するというタスクの内、IMEが担当するのはどの部分なのか？ インプットメソッドとは？ 前後の文脈を判断して変換候補に反映させたりできるのか？ 辞書はどのように作られているのか？ 辞書はどのように導入できるのか？ 複数の辞書を導入しても衝突しないか？ 複数のIMEに共通する規格はあるのか？ そもそも辞書とはどのような構造なのか？読み→漢字のペア以外にどんな追加のデータを含んでいるのか？

さすがに今日はユーザー辞書について調べた

ut辞書のビルドはできた sh ではなくbashでスクリプトを実行しないと生成できない

問題は、生成した辞書をmozcに組み込むところだ。 mozcではユーザー辞書を使って変換候補を拡張することができるのだが、実はut辞書はmozcのユーザー辞書の形式になっておらず、インポートすることができない。 ではどうやって利用するのかというと、mozcのビルド時に既存の辞書に結合して使う。 なぜ素直にインポート可能な形式にしないのかと疑問に思ったが、単に後から単語を追加するだけだと変換精度が悪くなるケースがあるようだ。 そもそもユーザー辞書では単なる(読み,書き)以上の情報を与えることができない。

そうなると、mozcを自力でビルドしなければならないということになる。 ビルドそのものは簡単に見える。公式でDockerfileが配布されていて、それを使ったビルド方法の説明が載っているからだ。 しかし実際はうまくいかなかった。 ビルド時のエラーメッセージを読んでみると、それがbazelによって自動生成されたファイルに由来している事が分かった。 bazelはgoogleのプロジェクトで使われているビルドシステムで、非常に活発に開発が行われ、高頻度のリリースが行われているようだった。 それ以外にbazelについて知っていることは全く無いため、別ののタグにチェックアウトしてビルドできないかどうか試した。 しかし、バージョン毎に異なるエラーに見舞われるだけだった。 不思議なのは、同じような症状を訴えるissueが全く無いことだった。 このリポジトリはCIを運用していて、少なくともビルドが通らなければタグを付けるはずがない。 そう考えてDockerfileを眺めていると、原因らしきものが見つかった。 このビルドに使用するコンテナイメージはubuntuをベースとしており、依存パッケージはaptでインストールする。 ほとんどのパッケージがdebianレジストリからインストールされる一方で、bazelなgoogleの管理するレジストリからインストールされていた。 そのため、bazelだけはバージョンを明示しなければならないが、件のDockerfileではbazelのバージョンを指定していなかった。 そのため、自分がビルドしようとしているmozcのバージョンがプッシュされたときのビルド環境と自分の手元の環境が異なるものになっていた。

原因がわかったので、明日はbazelのバージョンを変えて試してみたい。

mozcのビルドができた。しかしテストを実行できない。GitHub Actionの実行環境のubuntuには予め多くのパッケージがインストールされているが、ubuntuの公式Dockerイメージには最小限のソフトウェアしかインストールされていない。 githubのページを参考に、bazelのバージョンを合わせ、jdkをインストールし、JAVA_HOMEを設定するようにした。 しかし、Githubの環境と同じようにbazelのバージョンを6にすると何故かビルドできないので、bazelのバージョンを5.3.1にしてビルドした。 すると、今度は/varパーティションが小さすぎて、テストのビルドが最後まで終わらない。新たにパーティションを切り直すのは大変なので諦めようかと思ったが、試す価値のありそうな方法がまだ残っていた。Dockerの代わりにpodmanを使うというものである。podmanはコンテナをユーザー毎に管理するらしく、共用のディレクトリである/varを圧迫しないだろうと考えた。

追記(2023-11-29)

mozcのビルドが途中でストップするのは、bazelのバージョンの不整合のせいではなかった。 現バージョンのmozcではbazelの最新バージョンを使用してビルドする際に、 pkgconfigにまつわる不具合が起こっていた。 そのワークアラウンドとして、リポジトリにqt6のpkgconfigを置いておき、そのパスを環境変数で渡すようになっている。

オリジナルのDockerfileでは、イメージのビルド時にmozcのリポジトリ全体をフェッチしてくるようになっていたが、ビルドコンテキストからソースファイルをコピーするようにしていた。 srcディレクトリのみをコピーしていたのでコンテナ内にはpkgconfigは存在せず、ビルドが失敗していた。