10月も下旬となるとめっきり日が短くなり、朝晩はずいぶん寒さを感じるようになってきました。残暑が長く続いた分、秋らしい季節の実感がないまま冬に突入している感じです。今年もあと2ヵ月、Plamo-5.0に向けた32ビット版と64ビット版の同期作業も最終段階に入ってきました。
さて、今回は前回に引き続いてパッケージ作りには欠かせないビルドスクリプトとその背景にあるビルドシステムについて取りあげてみます。
GNU Autotools
前回PlamoBuildスクリプトの例として紹介したXfce用のファイルマネジャーThunarは、configureを用いてビルド環境を構築するようになっており、configure ; make ; make install だけでビルド、インストールできます。
このconfigureスクリプトはGNUプロジェクトが開発したAutotoolsと呼ばれる開発システムの一部です。
GNUプロジェクトでは、開発したソフトウェアをさまざまなUNIX風OSの上で動作させるために、CPUやOSの種類、コンパイラ等のビルドツールの機能の違い等を吸収するAutotoolsというビルドシステムを開発しました。Autotoolsは、configureスクリプトを生成するautoconf、configureで調べた結果を元に環境に応じたMakefileを生成するautomake、OSが共有(動的)ライブラリ機能を持っているかどうかに関わらずライブラリ操作を共通化するためのlibtoolsの3つのツールを使って、一つのソースコードをさまざまなUNIX風OS環境でビルドできるようにしています。
GNU Autotoolsは、設定ファイルの記述に独自のマクロ言語を使う必要があったりしてやや敷居は高いものの、最近のOSSプロジェクトの多くが採用しており、人気のあるソフトウェアでは、たいていconfigureを実行するだけでビルドが可能になっています。
Autotoolsを採用したソフトウェアは、ソフトウェアの種類によらず同じ手順でビルドできるので、名称やバージョン、入手先等を記述している10行ほどのヘッダ部を修正すれば、前回紹介した典型的なPlamoBuildスクリプトを流用することが可能です。
かってはImakeという独自のビルドシステムを利用していたX Window Systemも、Release7以降ではAutotoolsに移行して、それぞれの部品ごとにconfigureとmakeを繰替せばいいようになっているので、ヘッダ部分をそれぞれのソフトウェアに合わせたPlamoBuildスクリプトを生成しておけば、Xを構成する多数のソフトウェアを一気にパッケージ化することも可能です。このような仕組みのおかげで、前回紹介したようなペースでのパッケージ作りが可能になっていたわけです。
CMake
上述のようにGNU AutotoolsはOSS界の標準ビルドツールの地位を占めていますが、設計された当時とはUNIX風OSの世界も様変りしていて、最近の環境では不便な部分もあちこちにあります。そのような点を改善しようという新しいビルドシステムがいくつか提唱されており、それらの中で、最近、急速に勢力を伸ばしているのがCMakeと呼ばれるビルドシステムです。
CMakeはGNU Autotoolsを参考にしながら設計された新世代のビルドシステムで、OS Xも含めたUNIX風のOSのみならず、Windows環境にも対応するクロスプラットフォーム性を誇っています。
CMakeはGNU Autotools同様、自身が直接ビルドプロセスを管理するわけではなく、専用の設定ファイル(CMakeLists.txt)に従って、それぞれのプラットフォームに応じたビルド用設定ファイル(MakefileやEclipse等のIDE環境向けのプロジェクトファイル等)を生成してくれます。CMakeは比較的新しいビルドシステムなものの、C++用の高度なライブラリであるBoostやMySQL、KDE4といった高名なプロジェクトが採用しており、WindowsやMac環境もターゲットにするソフトウェアプロジェクトで積極的に採用されているようです。
CMakeはGNU Autotools同様、設定ファイルに従ってそれぞれの環境に応じたMakefileを生成するようになっていますが、変数やパス名の指定方法はconfigureスクリプトとは大きく異なります。たとえば、KDE-4.9.2に含まれているkdelibs-4.9.2の場合、ビルドスクリプトのヘッダ部は以下のような形になっています。
前回紹介したThunar-1.4.0のビルドスクリプトと比べると、10行目のOPT_CONFIGの指定がずいぶん異なっていることに気づくでしょう。この例のように、CMakeでは、-Dで指定したい項目を指示し、その項目が変数かパス名かなども指定する必要があります。
一方、このビルドスクリプトのconfigを引数にした際の処理は以下のようになっています。
CMakeの場合、ソースコードのあるディレクトリとビルド作業を行うディレクトリを分けることが推奨されているので、ソースコードを作業用ディレクトリにコピーする作業は省き(129-131行)、パッチはソースコードのあるディレクトリ($S)で当てた上で(137-143行)、作業用ディレクトリ($B)に移って、cmakeコマンドを実行します(151行)。
cmakeコマンドには、configureの場合同様、ビルドしたコマンドやライブラリのインストール先(-DCMAKE_INSTALL_PREFIX:PATH=..)を設定した上で、ソースコードのあるディレクトリ($S)を引数に指定します。この指定で、$Sディレクトリ以下にあるCMake用の設定ファイル(CMakeLists.txt)を元に、環境に応じたMakefileが生成されます。
config時の処理は大きく異なるものの、cmakeコマンドはそれぞれの環境に応じたMakefileを生成するので、buildやinstall時の処理はGNU Autotoolsを採用しているソフトウェアと同様、makeとmake installで済みます。
このように、CMakeを採用しているソフトウェアでも、GNU Autotoolsを採用しているソフトウェア同様、ビルドスクリプトのひな形を用意しておけば、後はヘッダ部分のファイル名やバージョン番号の修正だけで対応でき、パッケージの大量ビルドが可能になるわけです。
その他のビルドシステムを持つソフトウェア
最近では多くのソフトウェアがGNU AutotoolsやCMakeといったビルドシステムを採用していますが、それらとは異なるシステムを採用しているソフトウェアもあります。
それらの代表例がPerlやPythonで開発されたソフトウェアです。PerlやPythonで書かれたソフトウェアの場合、CPUやOS環境の違いなどはPerlやPythonのレベルで吸収してくれるので、GNU Autotoolsのような細かな環境チェックを行う必要がなく、PerlやPythonのバージョン、必要なモジュールの有無程度のチェックで済みます。そのためPerlもPythonもそれぞれ独自のビルドシステムを用意しています。
Perlの場合、Makefile.PLというPerlスクリプトが用意され、このスクリプトから、そのソフトウェアをビルド、インストールするためのMakefileを生成するようになっています。生成されたMakefileは、他のビルドシステムの場合と同様の手順でビルドできますので、ビルドスクリプトではconfigureの代わりにperl Makefile.PLしておけば、build(make)とpackage(make install)の処理は標準のビルドスクリプトを利用できます。
たとえば、PerlにURI処理機能を追加するモジュールをビルドするためのスクリプト(PlamoBuild.URI-1.60)ではconfig時の処理を以下のようにしています。
Pythonの場合はより徹底して、setup.pyというPythonスクリプトのみでビルドもインストールもできるようになっています。このスクリプトではconfigureに該当する処理は不要で、makeの代わりにpython ./setup.py buildを、make installの代わりにpython ./setup.py installを実行すればいいようになっています。
そのため、たとえばPythonにnotify機能を追加するモジュールをビルドするためのPlamoBuild.py-notify-0.3.1では、buildとpackageの処理は以下のようにしています。
一方、GNU Autotoolsが普及する以前に開発されたソフトウェアでは、設定ファイル等の調整がかなり面倒なことになります。Plamoの場合、KDEやXfceといった統合デスクトップ環境が普及する以前の「ウィンドウマネージャ」を支持する人が結構いるので、当時のソフトウェアもいくつか収録しています。それらのうち、当時広く使われていたAfterStepClassicのビルドスクリプトでは、config時の処理は以下のようになっています。
AfterStepClassicでは、当時のX Window Systemが採用していたImakeビルドシステムを利用しており、273行目に実行しているxmkmfコマンドが、あらかじめ用意されたImakefileから環境に応じたMakefileを生成します。しかしながら、Imakeでは対応できないconfigure.hやsample.steprcは個別にsedで修正したり、xmkmfで生成したMakefileもMANPATHの部分が現在の標準とはずれているので別途修正したりしています。
このビルドスクリプトには、同様の修正作業があちこちにあり、このあたりの処理を自動的にやってくれる最近のビルドシステムに慣れた身には、それらを確認するだけでも大変です。
開発元のX自体がGNU Autotoolsに移行してImakeシステムを放棄してしまったので、この世代のソフトウェアはそろそろ退役させる時期かな、という気もしていますが、根強いニーズもあるし、ビルドが今のように簡単ではなかった時の記憶のためだけでも残しておく価値があるように思っています。
ビルドスクリプト自動生成ツール
以上紹介してきたように、最近のソフトウェアの多くはGNU AutotoolsやCMakeといった汎用的なビルドシステムを採用しており、それらのソフトウェアはほぼ定型的な処理でビルド、インストールできるようになっているので、ビルドスクリプトも定型化できます。
そのような定型化したビルドスクリプトを作るためのメタ・ビルドスクリプト(make_PlamoBuild.py)はこの連載でも以前紹介したことがありますが、最近のバージョンはメンテナの加藤さんがgithubで公開してくれています。
最近のmake_PlamoBuild.pyは、GNU AutoconfとKDE用のCMakeの双方に対応しており、デフォルトではconfigureを使うGNU Autoconf用、-t KDEオプションを指定すると、インストール先を/opt/kde/に指定したCMake用のビルドスクリプトを生成します。また、引数としてソースコードの入手先のURLを指定すれば、ヘッダのURL部に自動的に埋めこむような機能も加えています。
このメタビルドスクリプトを使えば、典型的なパッケージ作成作業は以下のような流れになります。例としてxz圧縮ユーティリティの最新版5.0.4をビルドしてみます。
これは余分な作業を省いた極端な例で、実際にパッケージを作成する場合には、ソースコードに付属のREADMEファイルを眺めたり、過去のビルドスクリプトを調べたり、configure --helpで表示される指定可能なオプション類を調べたりします。しかし処理の基本的な流れはここに示した通りで、特に調整が不要なソフトウェアならば、それほど時間をかけずにパッケージ化することが可能です。