Fedora 20 で mozc-1.15.1834.102 をビルドしてみたの巻
Twitter から始まり、このブログのコメント欄でのやり取りに発展した mako999 さんとの Fedora 20 での mozc のビルドに関する話ですが、私自身がちょっと興味を持ったこともあって、Fedora 20 LXDE (64bit) を実際にインストールして mozc のビルドの検証を行ってみました。
※ インストールするデスクトップ環境に LXDE を選択したのには特別な意味はありません。ただ単に ISO イメージのファイルサイズが一番小さかったからです。(^_^;)
そして公式パッケージの mozc-1.15.1814.102-1.fc20.src.rpm の SPEC ファイルを基にして、これに修正を加えて 1.15.1834.102 をビルドすることに成功しました。
そのソースパッケージを置いておきます。
以下、SPEC ファイルでの 1.15.1814.102 からの変更点などを書いておきます。(SPEC の %changelog セクションにも変更点を書いています)
Fedora のユーザーさんで「自分で mozc-1.15.1834.102 をビルドしてみよう」と考えておられる方の何かの参考になれば幸いです。
- 1) 今回のビルドで使用している mozc のソースについて
-
mozc では 1.13.1651.102 以降、ソースは tar 玉では提供されていません。従って何らかの方法で mozc のリポジトリから取得する必要があるのですが、私は LinuxBuildInstructions のページの Get the Code の手順に準じてソースを取得しています。この手順で取得したソースには、mozc のビルドに必要となる protobuf や gyp などのサードパーティー製のツールも含まれています。
さらに 1.15.1834.102 からはビルドに ninja が必要になったことから、depot_tools に含まれている ninja, ninja-linux32, ninja-linux64, ninja-mac, ninja.exe の5つのファイルを取り出して来て、mozc のソースの build_tools ディレクトリ下に置いています。
※ build_tools ディレクトリ下に置いたのは私の勝手な判断であり、「このディレクトリでなければならない」ということではありません。また、Linux でのビルドには ninja-mac や ninja.exe は必要ありませんが一応置いてあります。
これらのソースを取得する手順を毎回手作業でやるのは面倒なので、自前でシェルスクリプトを書いて使っています。今回のソースパッケージにはこのスクリプト (mozc-svn-checkout.sh) を同梱しています。エラー処理などが甘いかなり稚拙なスクリプトですが、「そのソースはどうやって取得したのだ?」という疑問に対する回答として同梱しています。
- 2) BuildRequires: gcc-c++ を追加
-
mozc のビルドでは必須の gcc-c++ が何故か BuildRequires で指定されていなかった為、これがインストールされていない環境で公式のソースパッケージをリビルドしようとするとビルドエラーとなってしまっていました。
- 3) ninja に付いて
-
Fedora が提供しているものを使用するか、depot_tools のものを使用するかの設定を行う
%define use_system_installed_ninja
を追加しました。これを 1 に設定した場合には Fedora が提供しているものを、0 に設定した場合には depot_tools のものを使用してビルドを行います。
なお、1 が設定された場合には、
BuildRequires: ninja-build
が同時に指定されます。 - 4) %build セクションに ninja を使用する為の PATH 設定を追加
-
- ★ Fedora が提供している ninja を使用する場合
Fedora では ninja という同名の別のアプリが存在しており、mozc のビルドで必要とされる ninja は ninja-build という名前で提供されています。その為 ninja-build パッケージをインストールしていても実行ファイル名の違いから mozc 側から ninja を認識できずにビルドエラーとなってしまいます。
mozc のソースにパッチを当ててビルドエラーを回避する手段も取れますが、今回は /usr/bin/ninja-build に対してビルドディレクトリ上に ninja という名前でシンボリックリンクを張り、さらにそのビルドディレクトリに PATH を通すというちょっと強引な方法を取っています。
※ ninja という同名の別のアプリがインストールされている環境も考慮して、ビルドディレクトリを PATH の先頭に置いています。
- ★ depot_tools の ninja を使用する場合
depot_tools から取り出してきた ninja を置いている mozc のソースの build_tools ディレクトリに対して PATH を通しています。
※ ninja という同名の別のアプリがインストールされている環境も考慮して、build_tools ディレクトリを PATH の先頭に置いています。
- 5) protobuf と gyp に付いて
-
Fedora が提供しているものを使用するか、mozc のソースに同梱されているものを使うかの設定を行う
%define use_system_installed_third_party
を追加しました。これを 1 に設定した場合には Fedora が提供しているものを、0 に設定した場合には mozc のソースに同梱されているものを使用してビルドを行います。
- 6) Qt3 関係の環境変数について
-
mako999 さんとのやり取りの中で私が最も困惑したのがこの件です。なぜ Fedora では事前に環境変数の設定(しかもそれが Qt3 関係)が必要なのか、当初は不可解でした。しかし実際に Fedora であれこれやってみて、やっと理解できました。
つまり Fedora では、qt3 パッケージがインストールされている環境では自動的に Qt3 関係の環境変数が設定されており、それが mozc のビルドに悪影響を与えてビルドエラーを引き起こすのですね。それ故に事前に環境変数の設定(リセット)が必要なのだと。(当然のことながら、qt3 パッケージがインストールされていない環境ではこの様な問題は発生しません)
この問題への対応策としては、
BuildConflicts: qt3
を設定する手段もあるのですが、これでは qt3 を必要としている人がビルドする場合の影響が大き過ぎます。そこで今回は、システムに qt3 パッケージがインストルされている場合には、Qt3 関係の環境変数をリセットする処理を %build セクションへ追加することにしました。なおこのリセットはビルドを行っているセッション内でのみ有効になりますので、システム側で設定されている Qt3 関係の環境変数の設定には影響を与えません。
- 7) mozc.xml に付いて
-
1.15.1834.102 では ibus-mozc が使用する mozc.xml の生成位置が変更されました。これに対応するため、%install セクションの該当部分を修正しました。
out_linux/Release/obj/gen/unix/ibus/mozc.xml
↓
out_linux/Release/gen/unix/ibus/mozc.xml - 8) %post セクションを追加
-
mozc パッケージのインストール後に、動作中の旧バージョンの mozc_server を終了させる様にしました。この処理を行わないと mozc_server のバージョン不整合によってシステム全体の動作が不安定となり、システムの再起動が必要となります。
- 9) Patch0: mozc-build-verbosely.patch を削除
-
このパッチはビルドの際に make に対して冗長 (verbose) モードにするオプションである V=1 を与える為のものでしたが、1.15.1834.102 からはビルドには make に替わって ninja が使用されるように仕様変更されましたから、このパッチ自体が意味の無いものになりました。
- 10) BuildRequires: openssl-devel を削除
-
mozc では 1.15.1785.102 から openssl は不必要になっています。
コメント
当初の説明が困惑させてしまった原因だと思いますが,文中にも書かれている通り素の状態であればqt3は無縁なのですが,google-chrome等を導入している環境ではpreで入ってしまう(^^;という内容をお伝えすべきでした。説明が足りず申し訳ありません。Ubuntu等では関係なかったと記憶していますが,Fedoraは前からです。
> エラー処理などが甘いかなり稚拙なスクリプトです
ご謙遜し過ぎでは?。
> ご謙遜し過ぎでは?
いえいえ、「取り敢えずソースを取得できればいいや」的な感じで作ったので、ネットワークが繋がらない場合のエラー処理だとか、その他色々な部分で手抜きになっています。(^_^;)