玩式草子─ソフトウェアとたわむれる日々

第39回 Plamo Linuxのビルドスクリプトとパッケージ管理ツール[その2]

この記事を読むのに必要な時間:およそ 6 分

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スクリプトを生成するautoconfconfigureで調べた結果を元に環境に応じたMakefileを生成するautomakeOSが共有(動的)ライブラリ機能を持っているかどうかに関わらずライブラリ操作を共通化するためのlibtoolsの3つのツールを使って,一つのソースコードをさまざまなUNIX風OS環境でビルドできるようにしています。

GNUプロジェクトが始まった80年代後半は,少しずつ仕様の異なるUNIX風OSを積んだ「ワークステーション」が乱立していました。AutotoolsはそのようなOS間のさまざまな違いを柔軟に吸収できるように,かなり複雑で大掛かりな仕組みになっていて,均質化が進んだ最近のPC UNIXの世界ではややオーバースペックでわずらわしい部分があります。

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++用の高度なライブラリであるBoostMySQLKDE4といった高名なプロジェクトが採用しており,WindowsやMac環境もターゲットにするソフトウェアプロジェクトで積極的に採用されているようです。

CMakeはGNU Autotools同様,設定ファイルに従ってそれぞれの環境に応じたMakefileを生成するようになっていますが,変数やパス名の指定方法はconfigureスクリプトとは大きく異なります。たとえば,KDE-4.9.2に含まれているkdelibs-4.9.2の場合,ビルドスクリプトのヘッダ部は以下のような形になっています。

 1  #!/bin/sh
 2  ##############################################################
 3  url='ftp://ftp.kddlabs.co.jp/X/kde/stable/4.9.2/src/kdelibs-4.9.2.tar.xz'
 4  pkgbase=kdelibs
 5  vers=4.9.2
 6  arch=x86_64
 7  # arch=i586
 8  build=P1
 9  src=kdelibs-4.9.2
10  OPT_CONFIG=' -DDOCBOOKXML_CURRENTDTD_DIR:PATH=/usr/share/xml/docbook/schema/4.2/dtd '
11  DOCS='AUTHORS COPYING COPYING.DOC COPYING.LIB INSTALL README README-WIN32.TXT TODO knewstuff licenses'
12  patchfiles=''
13  compress=txz
14  ##############################################################

前回紹介したThunar-1.4.0のビルドスクリプトと比べると,10行目のOPT_CONFIGの指定がずいぶん異なっていることに気づくでしょう。この例のように,CMakeでは,-Dで指定したい項目を指示し,その項目が変数かパス名かなども指定する必要があります。

一方,このビルドスクリプトのconfigを引数にした際の処理は以下のようになっています。

128  if [ $opt_config -eq 1 ] ; then
129    for i in `seq 0 $((${#B[@]} - 1))` ; do
130      if [ -d ${B[$i]} ] ; then rm -rf ${B[$i]} ; fi ; mkdir -p ${B[$i]}
131    done
132  ######################################################################
133  # * ./configure を行う前に適用したい設定やパッチなどがある場合はここに
134  #   記述します。
135  ######################################################################
136    for i in `seq 0 $((${#S[@]} - 1))` ; do
137      cd $S
138      for patch in $patchfiles ; do
139         if [ ! -f ".$patch" ]; then
140             patch -p1 < $W/$patch
141             touch ".$patch"
142         fi
143      done
144  
145     cd $B
146        if [ -f $S/CMakeLists.txt ]; then
147            export PKG_CONFIG_PATH=/opt/kde/${libdir}/pkgconfig:/usr/${libdir}/pkgconfig:/usr/share/pkgconfig
148            export LDFLAGS='-Wl,--as-needed' 
149            export CC="gcc -isystem /usr/include $target" 
150            export CXX="g++ -isystem /usr/include $target"
151            cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/kde -DLIB_INSTALL_DIR:PATH=/opt/kde/${libdir} -DLIB_SUFFIX=$suffix ${OPT_CONFIG} $S
152        fi

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を採用しているソフトウェアと同様,makemake installで済みます。

このように,CMakeを採用しているソフトウェアでも,GNU Autotoolsを採用しているソフトウェア同様,ビルドスクリプトのひな形を用意しておけば,後はヘッダ部分のファイル名やバージョン番号の修正だけで対応でき,パッケージの大量ビルドが可能になるわけです。

著者プロフィール

こじまみつひろ

Plamo Linuxとりまとめ役。もともとは人類学的にハッカー文化を研究しようとしていたものの,いつの間にかミイラ取りがミイラになってOSSの世界にどっぷりと漬かってしまいました。最近は田舎に隠棲して半農半自営な生活をしながらソフトウェアと戯れています。

URLhttp://www.linet.gr.jp/~kojima/Plamo/index.html

コメント

コメントの記入