前回までにPlamoBuildスクリプトの基本的な使い方を紹介しました。今回は、もう少し踏み込んだ使い方を紹介します。
設定オプションの指定
ソースコードに必要な設定を施すconfigureスクリプトは、オプション引数で動作を調整することができます。前回取りあげた--disable-static --enable-sharedなどが代表的なオプション引数です。
オプション引数には、インストール先を指定する--prefix=..や設定ファイルの置き場所を指定する--sysconfdir=..など、configureを採用しているほとんどのソフトウェアで使用可能なものと、それぞれのソフトウェアごとに用意されたものがあります。
どのようなオプション引数が使用可能かはconfigure --helpで確認できます。前回までに紹介してきたfluxboxの場合、以下のようなオプションが用意されています。
各引数はそれぞれどのような機能を追加、あるいは削除するかを指定し、引数を指定しなかった場合のデフォルト値が括弧内に記載されています。このリストを見ると、82行目の"--enable-debug"と83行めの"--enable-test"というデバッグ以外の機能は(default=yes)となっており、敢えて指定する必要はなさそうです。
一方、ライブラリ等が不足していて特定の機能を無効にしたい場合は、"--enable-xmb=no --disable-fribidi"のように指定することになります。
PlamoBuildスクリプトではconfigureに渡す引数はヘッダ部のOPT_CONFIGで設定します。上記設定の場合、前回紹介したPlamoBuild.fluxbox-1.3.7の9行目に追加することになります。
この設定は、configureを起動している59行目に直接追加してもいいものの、「configureオプションをどう設定したか」はパッケージにとって重要な意味を持つので、PlamoBuildスクリプトを開けばすぐ目に入る、ヘッダ部分に設定するようにしています。
設定オプションの虎の巻
紹介してきたfluxbox-1.3.7のように、最近では多くのソフトウェアがあらかじめ用意されたデフォルト値で最適な設定になるよう調整されています。しかしながら、設定オプションでの機能調整が必須なソフトウェアもよくあり、どのような設定オプションを指定するかはパッケージ作成時の悩みの種です。
設定オプションに悩んだ時は、他のディストリビューションを参考にするのが便利です。手元では、主にLFS/BLFSかArch Linuxのビルドスクリプトを見ています。
LFS(Linux From Scratch)/BLFS(Beyond Linux From Scratch)は本連載でも何度か紹介したことがあるように、必要最小限の機能を目指した設計になっており、彼らが選択している設定オプションはどのLinux環境でも必要になります。
一方、Arch Linuxは、シンプルながら先進的で高機能な環境を目指していて、新しく追加された機能なども積極的に採用しています。そのため両者を見比べれば、可能な設定範囲はほぼカバーでき、その中からPlamo Linuxに必要な機能を考えることができます。
取りあげてきたfluxboxの場合、BLFSでは"./configure --prefix=/usr"となっているのに対し、Arch Linuxでは"./configure --prefix=/usr --enable-imlib2 --enable-nls --enable-xft --enable-xinerama"となっていました。
Arch Linuxで指定している各オプションの意味は何だろう、とヘルプメッセージを調べたところ、先に紹介したように、それら機能はデフォルトで"yes"になっていたため、OPT_CONFIGには何も指定する必要はないだろう、と判断した次第です。
主要ディストリビューションであるRedHat/Fedora系やDebian系も重要なものの、SRPMや.deb.tar.xzといった独自のビルドシステムを構築しているこれら系統よりも、コマンドラインやシェルスクリプトをそのまま流用できるLFS/BLFSやArch Linuxの方が、Plamo Linuxからは利用しやすいです。
なお、LFS/BLFSでは、ソースコードを修正する際、パッチファイルではなくsed等のコマンドを多用しています。そのような修正をPlamoBuildスクリプトに取り込む場合、設定処理部のconfigureスクリプトを起動する前、前回紹介したPlamoBuild.fluxbox-1.3.7を例にすれば、47行目から56行目の間あたりに追加する必要があります。
configure以外への対応
make_PlamoBuild.pyはconfigure以外にもCMake、Pythonのsetup.py、PerlのMakefile.PLに対応しており、それぞれに応じたPlamoBuildスクリプトを作ります。といっても、違いはconfigureの代わりにcmakeやsetup.pyを実行する程度です。
たとえば、Qtを用いたターミナルソフトqterminal-0.8.0はビルドシステムにCMakeを使っており、設定にcmakeコマンドを使います。
cmakeコマンドはconfigureと同じように、システムにインストールされているライブラリ等を調べてその環境に適したMakefileを作るので、以後の処理はconfigure同様、makeコマンドが担います。
Perl用のソフトウェアが採用しているMakefile.PLも、環境に応じたMakefileを作るように設計されており、ビルドやパッケージ化にはmakeコマンドを用います。
一方、Python用のソフトウェアはsetup.pyというPythonスクリプトで設定からビルド、インストールまで対応しています。以下に示すのはPythonで書かれたカードゲームPySolFC-2.2.0用のビルドスクリプトの設定からインストールするまでの処理で、52行目の設定、62行目のビルド、73行目のインストールそれぞれが"setup.py"によって実行されています。
これら4種のビルドシステムはmake_PlamoBuild.pyが見分けられるので、設定オプションの調整程度の作業でパッケージ作成が可能です。また、最新版のmake_PlamoBuild.pyでは、新しくmeson/ninjaビルドシステムにも対応しました。
適切な設定方法が見つからない場合
make_PlamoBuild.pyは、ソースコード中にconfigure、CMakeList.txt、Makefile.PL、setup.pyのいずれかのファイルを見つけた場合、それぞれに応じたPlamoBuildスクリプトを作ります。一方、ソースコード中にこれらのファイルが無かった場合は、「適切な設定方法がわからない」旨のメッセージを出して、configure用のビルドスクリプトを作ります。
この場合、ビルドスクリプトを手動で調整する必要があります。どのように調整するかはソフトウェアにより異なるため、詳細についてはソースコードに付属のドキュメント類を調べることになるものの、大きく分けると「SConsやWAFなど未対応のビルドシステムを利用している」場合、「あらかじめMakefileが用意されている」場合、「autogen.shを実行してconfigureスクリプトを生成する」場合などがあります。
これらのうち「あらかじめMakefileが用意されている」場合の例として、FDcloneと呼ばれるテキストベースのファイルマネージャをビルドしてみましょう。FDcloneは、元々MS-DOS用に開発された"FD"というファイルマネージャを参考に、UNIX系OS用に開発されたファイルマネージャで、コンソール環境でも一覧画面からファイルを操作できる便利なツールです。
FDcloneの最新版はftp.unixusers.netで公開されているので、まずこのソースコードを入手し、手もとの作業用ディレクトリに展開しておきます。
次に、展開したソースコードディレクトリに対してmake_PlamoBuild.pyを実行します。FDcloneにはconfigure等のファイルが無いため、「適切な設定方法がわからない」旨のメッセージが表示されました。
このままでは、configureスクリプトが無いため、エラーになってビルドスクリプトを実行できません。
一方、FD-3.01hのソースコードを調べると、READMEやInstallといったドキュメントと共にMakefileも用意されており、ソースコードディレクトリでmakeを実行すると、問題なくビルド作業が始まります。
Makefileが用意されているなら直接ビルドできるのかな、と考えて、PlamoBuildスクリプトを"build"オプションで起動してもエラーになります。
このトラブルは、PlamoBuildスクリプトでは、ソースコードディレクトリとビルド作業用ディレクトリを分けていることが原因で、FDcloneのようにソースコードディレクトリ内でしかビルドできないソフトウェアでは、まずソースコードをビルド作業用ディレクトリにコピーしてやる必要があります。
元のビルドスクリプトの設定部分はこうなっていました。
このコードの$Bがビルド作業用ディレクトリ(/tmp/build)で、45行目に見るように、設定処理を行なう毎にこのディレクトリは作り直されます。そこで、この部分を次のように直しました。
少し43行目のコメントも直していますが、重要なのは45行目で、空のディレクトリを作る代わりにソースコードディレクトリを全てコピーしています。
configureは不要なので削除し、53行目でopt_buildフラグを立てて、自動的にビルド作業に進むようにしました。この修正でコンパイルはできるようになりました。
しかしながら、パッケージを作成しようとすると、「インストール先に書き込めない」旨のエラーになります。
このエラーは、一般ユーザ権限で/usr/local/binに書き込もうとしたことが原因で、インストール先を一般ユーザ領域にするためのmake install DESTDIR=$Pが機能していないようです。
"make install DESTDIR=..."はインストール先を変更するための指定ですが、インストール先を変更するためのオプションはソフトウェアによって異なり、"DESTDIR=..."とするものが多いものの、"INSTALLROOT=..."だったり、"prefix=..."だったりすることがあります。
インストール先をどう指定するかはMakefile等を調べる必要があり、FDcloneの場合はPREFIX=...という指定になるようです。そこで、この設定もPlamoBuildスクリプトに反映します。
PlamoBuildスクリプトは"config"オプションを指定した際にビルド用ディレクトリが初期化されるようになっています。逆に言うと、"config"オプションを再実行するまでビルド用ディレクトリはそのまま保持されるので、一度ビルドが通っていれば、パッケージ化のみをやり直せます。
上記の"make install PREFIX=$P/usr"の指定で、必要なファイルがインストール用ディレクトリに正しくインストールされ、パッケージも無事作成できました。
必要なファイル類が正しく収められているのを確認すれば、念のため、再度PlamoBuild.FD-3.01hスクリプトを最初から実行し直し、root権限でパッケージ化して、Plamo Linux用FDcloneパッケージの完成となります。
今回取りあげたFDcloneのように、configure等の標準的なビルドシステムを採用していないソフトウェアをパッケージ化するのは少し面倒なものの、現在ではこのような個別対応が必要となるソフトウェアは少数派で、たいていのソフトウェアはmake_PlamoBuild.pyで作成したビルドスクリプトのままパッケージ化することができます。
しかしながら、自動生成したビルドスクリプトだけで作れるパッケージだけでは飽き足らず、この種の手のかかるパッケージの方に作りがいを感じてしまうのは、メンテナの性(さが)というものでしょうか?(苦笑)