最後の bash 例解 の記事で、Daniel Robbins 氏は Gentoo Linux ebuild システムを取り上げています。これは bash のパワーを示す優れた例となっています。ebuild システムがどのように実装されるかを段階的に示し、数多くの手ごろな bash の技法や設計戦略に触れています。記事の終わりまでには、本格的な bash ベースのアプリケーションの製作に何が関係しているかを十分に把握し、独自の自動ビルド・システムのコーディングを始めることができるでしょう。

Daniel Robbins, President and CEO, Gentoo Technologies, Inc.

アメリカはニューメキシコ州アルバカーキ (Albuquerque) 在住の Daniel Robbins 氏は、Gentoo Project の責任者、Gentoo Technologies, Inc. の CEO、Linux Advanced Multimedia Project (LAMP) の良き指導者、「Caldera OpenLinux Unleashed」、「SuSE Linux Unleashed」、「Samba Unleashed」などの Macmillan 書籍の共同執筆者という多彩な肩書きを有しています。コンピューターとのかかわりは小学校 2 年生のころからであり、Logo プログラミング言語と、ちょっと怖いパックマンとの出会いがきっかけでした。そういう生い立ちもあってか、SONY Electronic Publishing/Psygnosis のリード・グラフィック・アーティストとしても活躍中です。この春に出産を予定している愛妻 Mary さんとの時間を大切にする良き夫でもあります。



2000年 5月 01日

ebuild システムの紹介

いよいよ 3 番目の、そして最後のbash 例解 の記事を取り上げることができます。これまでのところで、bash プログラミングの基礎について 第 1 回第 2 回 で網羅しましたので、bash アプリケーション開発やプログラム設計などの高度なトピックに焦点を合わせることができます。この記事では、コーディングと洗練にかなり時間を費やした、Gentoo Linux ebuild システムのプロジェクトを紹介することにより、実際的で現実的な bash 開発の経験のいくらかを分かち合いたいと思います。

Gentoo Linux は現在ベータ段階にある次世代 Linux OS であり、私はその主任アーキテクトです。私の主な責任の一つは、すべてのバイナリー・パッケージ (RPM パッケージのようなもの) が適切に作成され、全体として一緒に機能することを確かめることです。おそらくご存知と思いますが、標準的な Linux システムは、(BSD のように) 1 つに統一されたソース・ツリーで構成されているのではなく、実際には、一緒に機能する約 25 かそれ以上のコア・パッケージによって成り立っています。それらのパッケージの一部を以下に示します。

パッケージ説明
linux実際のカーネル
util-linux種々の Linux 関連プログラムの集合
e2fsprogsext2 ファイル・システム関連ユーティリティーの集合
glibcGNU C ライブラリー

各パッケージはそれぞれ専用の tarball に入っており、それぞれ独立した開発者または開発チームによって保守されています。配布物を作成するには、各パッケージを別々にダウンロードし、コンパイルし、そしてパッケージする必要があります。パッケージの修正、アップグレード、または改良のたびに、コンパイルとパッケージのステップを繰り返す必要があります (これにより、古いものも本当に高速になります)。パッケージの作成と更新に関係する反復的なステップを減らせるよう、ebuild システムを作成しました。これはほとんど全体が bash で書かれています。bash の知識を増進できるよう、ebuild システムのアンパックとコンパイルの部分をどのように実装したかを、ステップごとに示していきます。各ステップを説明しながら、特定の設計上の決定を下した理由についても論じます。この記事の終わりまでには、大規模な bash プログラミング・プロジェクトについて見事に把握できるだけでなく、完全な自動ビルド・システムのかなりの部分を実装することができているでしょう。


なぜ bash なのか?

bash は Gentoo Linux ebuild システムの不可欠な構成要素です。それはいくつもの理由から、ebuild の主要な言語に選択されました。まず第一に、その構文が複雑でなく、なじみやすいものであり、外部プログラムの呼び出しに特に適しています。自動ビルド・システムは外部プログラムの呼び出しを自動化する "グルー (糊) コード" であり、bash はこの種のアプリケーションに最適です。第二に、bash の関数に対するサポートによって、ebuild システムのコードはモジュール化された理解しやすいものとなります。第三に、ebuild システムは環境変数に対する bash のサポートを利用しており、それによってパッケージの保守担当者や開発者はその場で簡単にパッケージを構成することができます。


ビルド・プロセスの検討

ebuild システムを調べる前に、パッケージのコンパイルとインストールに何が関係しているかを振り返ってみましょう。この例では、"sed" パッケージを調べていきます。これは標準的な GNU テキスト・ストリーム編集ユーティリティーであり、Linux 分配物に含まれています。最初に、ソース tarball (sed-3.02.tar.gz) をダウンロードします (参考文献を参照)。このアーカイブを /usr/src/distfiles に保管します。このディレクトリーは "$DISTDIR" 環境変数を使って参照することになります。"$DISTDIR" は、オリジナルのソース tarball すべてを入れておくディレクトリーであり、ソース・コードの大きな "金庫室" になります。

次のステップは、"work" という一時ディレクトリーを作成することです。ここには圧縮解除したソースを入れます。後で "$WORKDIR" 環境変数を使ってこのディレクトリーを参照することになります。これを行うには、書き込み許可のあるディレクトリーに移動して、次のように入力します。

Uncompressing sed into a temporary directory
$ mkdir work
$ cd work
$ tar xzf /usr/src/distfiles/sed-3.02.tar.gz

これで tarball が圧縮解除されるとともに、すべてのソースを収容する sed-3.02 というディレクトリーが作成されます。後で "$SRCDIR" 環境変数を使って sed-3.02 ディレクトリーを参照することになります。プログラムをコンパイルするために、次のように入力します。

Uncompressing sed into a temporary directory
$ cd sed-3.02
$ ./configure --prefix=/usr
(autoconf は適切な makefile を生成します。これには少し時間がかかります。)
$ make
(パッケージがソースからコンパイルされますが、これにも少し時間がかかります。)

この記事ではアンパックとコンパイルのステップだけを網羅しているので、次に "make install" ステップに飛びます。これらすべてのステップを実行してくれる bash スクリプトを書きたいのであれば、下記のようなものにできます。

Sample bash script to perform the unpack/compile process
#!/usr/bin/env bash
if [ -d work ]
then
# remove old work directory if it exists 
	rm -rf work
fi
mkdir work
cd work
tar xzf /usr/src/distfiles/sed-3.02.tar.gz
cd sed-3.02
./configure --prefix=/usr
make

コードの標準化

この自動コンパイル・スクリプトは機能しますが、あまり柔軟性はありません。基本的に bash スクリプトには、コマンド行に入力するすべてのコマンドのリストが入っているだけです。このソリューションでも使えますが、ほんの数行を変更するだけでどんなパッケージでもすばやくアンパックしてコンパイルするように構成できる、汎用のスクリプトを作成できるとよいでしょう。そのようにすれば、配布物に新しいパッケージを追加する際のパッケージ保守担当者の作業はずっと少なくなります。これを行う最初の試みとして、いろいろな環境変数を使って、ビルド・スクリプトをもっと汎用性のあるものにしてみましょう。

A new, more general script
#!/usr/bin/env bash
# P is the package name
P=sed-3.02
# A is the archive name
A=${P}.tar.gz
export ORIGDIR=`pwd`
export WORKDIR=${ORIGDIR}/work
export SRCDIR=${WORKDIR}/${P}
if [ -z "$DISTDIR" ]
then
	# set DISTDIR to /usr/src/distfiles if not already set
	DISTDIR=/usr/src/distfiles
fi
export DISTDIR
if [ -d ${WORKDIR} ]
then	
	# remove old work directory if it exists 
	rm -rf ${WORKDIR}
fi
mkdir ${WORKDIR}
cd ${WORKDIR}
tar xzf ${DISTDIR}/${A}
cd ${SRCDIR}
./configure --prefix=/usr
make

たくさんの環境変数をコードに追加しましたが、基本的にしていることは同じです。しかしこのたびは、任意の標準的な GNU autoconf ベースのソース tarball をコンパイルするために、単にこのファイルを新しいファイルにコピーし (その名前は、コンパイルする新しいパッケージの名前を反映したものとする)、ついで、"$A" と "$P" の値を新しい値に変更することができます。他のすべての環境変数は正しい設定値に自動的に調整され、スクリプトは期待通りに機能します。これは使いやすいものですが、さらにコードに改良を加えることができます。この特定コードは、最初に作成した "transcript" スクリプトよりもかなり長くなっています。すべてのプログラミング・プロジェクトの目標の 1 つはユーザーにとっての複雑さを減らすことですから、コードを劇的に短縮できればすばらしいことですし、少なくともコードを組織化するのは良いことです。これは巧みなトリックによって達成できます。コードを 2 つの別々のファイルに分けるのです。次のファイルを "sed-3.02.ebuild" として保管しましょう。

sed-3.02.ebuild
#the sed ebuild file -- very simple!
P=sed-3.02
A=${P}.tar.gz

第 1 のファイルは小さなもので、各パッケージごとに構成する必要のある環境変数だけが入っています。次は第 2 のファイルですが、これは操作の首脳部になります。次のファイルを "ebuild" として保管し、実行可能ファイルを作成しましょう。

The ebuild script
#!/usr/bin/env bash

if [ $# -ne 1 ]
then
	echo "one argument expected."
	exit 1
fi
if [ -e "$1" ]
then
	source $1
else
	echo "ebuild file $1 not found."
	exit 1
fi
export ORIGDIR=`pwd`
export WORKDIR=${ORIGDIR}/work
export SRCDIR=${WORKDIR}/${P}
if [ -z "$DISTDIR" ]
then
	# set DISTDIR to /usr/src/distfiles if not already set
	DISTDIR=/usr/src/distfiles
fi
export DISTDIR
if [ -d ${WORKDIR} ]
then	
	# remove old work directory if it exists 
	rm -rf ${WORKDIR}
fi
mkdir ${WORKDIR}
cd ${WORKDIR}
tar xzf ${DISTDIR}/${A}
cd ${SRCDIR}
./configure --prefix=/usr
make

これで、ビルド・システムを 2 つのファイルに分けたわけですが、どのようにして機能するのか不思議に思われることでしょう。基本的に、sed をコンパイルするには、次のように入力します。

$ ./ebuild sed-3.02.ebuild

"ebuild" が実行されるとき、まず "source" 変数 "$1" を試行します。これはどういう意味でしょうか。前の記事 で述べましたが、"$1" は最初のコマンド行引数です。このケースでは "sed-3.02.ebuild" になります。bash では、"source" コマンドはファイルから bash ステートメントを読み取り、"source" コマンドが入っているファイルに直接現れているかのようにそれらを実行します。それで、"source ${1}" により、"ebuild" スクリプトは "sed-3.02.ebuild" にあるコマンドを実行し、ここでは "$P" と "$A" が定義されます。この設計変更は大変便利なものです。というのは、sed 以外のプログラムをコンパイルしようとする場合、新しい .ebuild ファイルを作ってそれを "ebuild" スクリプトへの引数として渡すだけでいいからです。そのようにして、.ebuild ファイルを実にシンプルなものにできる一方、ebuild システムの複雑な首脳部は一箇所 ("ebuild" スクリプト) に格納しておくことができます。このように、"ebuild" スクリプトを簡単に編集するだけで、インプリメンテーションの詳細を ebuild ファイルの外部に保管しながら、ebuild システムをアップグレードもしくは機能強化することができます。gzip 用のサンプル ebuild ファイルを以下に示します。

gzip-1.2.4a.ebuild
#another really simple ebuild script!
P=gzip-1.2.4a
A=${P}.tar.gz

機能性の追加

ここまでで、かなり前進することができました。しかし、さらに追加したいいくつかの機能性があります。ebuild スクリプトが第 2 のコマンド行引数を受け入れるようにしたいと思います。それは、"compile"、"unpack"、または "all" です。第 2 のコマンド行引数は ebuild スクリプトに、ビルド・プロセスのうちのどの特定のステップを実行すべきかを知らせます。そのようにして、アーカイブをアンパックするけれどもコンパイルはしないことを ebuild に指示できます。(コンパイルを始める前にソース・アーカイブを調べたい場合にこれが該当します。) これを行うには、変数 "$2" をテストするケース・ステートメントを追加し、その値によって別々のことを行うようにします。コードは以下のようになります。

ebuild, revision 2
#!/usr/bin/env bash
if [ $# -ne 2 ]
then
	echo "Please specify two args - .ebuild file and unpack, compile or all"
	exit 1
fi

if [ -z "$DISTDIR" ]
then
	# set DISTDIR to /usr/src/distfiles if not already set
	DISTDIR=/usr/src/distfiles
fi
export DISTDIR
ebuild_unpack() {
	#make sure we're in the right directory	
	cd ${ORIGDIR}
	
	if [ -d ${WORKDIR} ]
	then	
		rm -rf ${WORKDIR}
	fi
	mkdir ${WORKDIR}
	cd ${WORKDIR}
	if [ ! -e ${DISTDIR}/${A} ]
	then
	 echo "${DISTDIR}/${A} does not exist.  Please download first."
	 exit 1
	fi 
	tar xzf ${DISTDIR}/${A}
	echo "Unpacked ${DISTDIR}/${A}."
	#source is now correctly unpacked
}

ebuild_compile() {
	
	#make sure we're in the right directory
	cd ${SRCDIR}
	if [ ! -d "${SRCDIR}" ]
	then
		echo "${SRCDIR} does not exist -- please unpack first."
		exit 1
 	fi
	./configure --prefix=/usr
	make	 
}
export ORIGDIR=`pwd`
export WORKDIR=${ORIGDIR}/work
if [ -e "$1" ]
then
	source $1
else
	echo "Ebuild file $1 not found."
	exit 1
fi
export SRCDIR=${WORKDIR}/${P}
case "${2}" in
	unpack)
		ebuild_unpack
		;;
	compile)
		ebuild_compile
		;;
	all)
		ebuild_unpack
		ebuild_compile
		;;
	*)
		echo "Please specify unpack, compile or all as the second arg"
		exit 1
		;;
esac

多くの変更を加えたので、振り返ってみましょう。まず、コンパイルとアンパックのステップを別々の関数に入れました。それぞれ、ebuild_compile() および ebuild_unpack() というものです。コードがより複雑になったので、これは適切な移動です。新しい関数によりいくらかのモジュール性が備わり、組織性が保てます。各関数の最初の行では、移動したいディレクトリーへ明示的に "cd" しています。これは、コードがリニアなものではなくモジュール性を持つものにしたいからであり、間違った現行作業ディレクトリーで関数を実行するという手違いを冒すことがよくあるからです。"cd" コマンドで明示的に正しい場所に移っておけば、後で間違いを冒さずにすみます。(特に、関数内部のファイルを削除するという、重要なステップでの間違いがあります。)

さらに、ebuild_compile() 関数の最初に、有用な検査を加えました。それは "$SRCDIR" の存在を確認し、存在しなければエラー・メッセージをプリントし、まずアーカイブをアンパックしてから終了するよう、ユーザーに通知します。望むならこの動作を、"$SRCDIR" が存在しないなら ebuild スクリプトがソース・アーカイブを自動的にアンパックするように、変更することもできます。ebuild_compile() を以下のコードに置き換えることで、これを行うことができます。

A new spin on ebuild_compile()
ebuild_compile() {
	#make sure we're in the right directory	 
	if [ ! -d "${SRCDIR}" ]
	then
		ebuild_unpack
 	fi
	cd ${SRCDIR}
	./configure --prefix=/usr
	make	 
}

ebuild スクリプトの 2 番目のバージョンでの目立った変更点の一つは、コードの最後に新しいケース・ステートメントを入れたことです。このケース・ステートメントは単に 2 番目のコマンド行引数を調べ、その値にしたがって正しいアクションを実行します。次のように入力した場合には、

$ ebuild sed-3.02.ebuild

エラー・メッセージを受け取ることになります。ebuild は以下のように、次に何をすべきかの指示を必要とします。

$ ebuild sed-3.02.ebuild unpack

または

$ ebuild sed-3.02.ebuild compile

または

$ ebuild sed-3.02.ebuild all

上記以外の 2 番目のコマンド行引数を入力した場合は、エラー・メッセージ (* 文節) を受け取り、プログラムは終了します。


コードのモジュール化

ここまでで、コードは先進的なものであり、機能性も十分ですが、お気に入りのプログラムをアンパックしてコンパイルするための さらにいくつかの ebuild スクリプトを作成したいと思われるかもしれません。その場合、遅かれ早かれ、autoconf ("./configure") を使わないいくつかのソース、あるいは標準的でないコンパイル・プロセスを持ついくつかのソースが思い浮かぶでしょう。ebuild システムにさらに変更を加えて、こうしたプログラムに適合するようにする必要があります。それを実行する前に、どのようにそれを成し遂げるかについて、少し考えてみるのは良いことです。

コンパイル段階に "./configure --prefix=/usr; make" という固定コードを入れた最大の理由は、たいていの場合にそれで機能するということです。しかし、autoconf や通常の Makefile を使用しないソースにも、ebuild システムを適合させなければなりません。この問題を解決するために、ebuild スクリプトがデフォルトで以下のことを行うようにすることを提案します。

  1. "${SRCDIR}" に構成スクリプトがある場合、次のように実行します。

    ./configure --prefix=/usr

    そうでない場合はこのステップをスキップします。
  2. 次のコマンドを実行します。

    make

ebuild が構成を実行するのは実際にそれが存在する場合だけなので、autoconf を使用せず標準的な makefile を持つようなプログラムに対して、これで自動的に適合できます。しかし、一部のソースに対して単純な "make" が通用しない場合はどうでしょうか?こうした状況にも対処できるように、妥当なデフォルトを、いくらかの特定コードによってオーバーライドする手段が必要です。それを行うため、ebuild_compile() 関数を変形して 2 つの関数に分けることにします。"親" 関数のように見える第 1 の関数は、やはり ebuild_compile() というものです。しかし、user_compile() という新しい関数を設けます。これには妥当なデフォルト・アクションだけを入れます。

ebuild_compile() split into two functions
user_compile() {
	#we're already in ${SRCDIR}
	if [ -e configure ]
	then
		#run configure script if it exists
		./configure --prefix=/usr
	fi
	#run make
	make
}	 
ebuild_compile() {
	if [ ! -d "${SRCDIR}" ]
	then
		echo "${SRCDIR} does not exist -- please unpack first."
		exit 1
	fi
	#make sure we're in the right directory	 
	cd ${SRCDIR}
	user_compile
}

ここで行ったことの理由がはっきり分からないかもしれませんが、ご勘弁ください。このコードは前述のバージョンの ebuild とほとんど同じように機能しますが、以前にはできなかったことが可能になっています。それは、sed-3.02.ebuild にある user_compile() をオーバーライドできるということです。それで、デフォルトの user_compile() 関数が必要にかなっていない場合は、パッケージをコンパイルするのに必要なコマンドを含む新しい関数を .ebuild ファイルに定義することができます。たとえば、e2fsprogs-1.18 用の ebuild ファイルがありますが、それは "./configure" の行が若干異なっている必要があります。

e2fsprogs-1.18.ebuild
#this ebuild file overrides the default user_compile()
P=e2fsprogs-1.18
A=${P}.tar.gz
 
user_compile() {
 ./configure --enable-elf-shlibs
 make
}

さて、e2fsprogs は期待通りにコンパイルされるはずです。しかし、ほとんどのパッケージについては、.ebuild ファイル内のカスタム user_compile() 関数は省略でき、デフォルトの user_compile() 関数が代わりに使用されます。

ebuild スクリプトは、どの user_compile() 関数を使用すべきかをどのように認識するのでしょうか?実は、これはとても単純です。ebuild スクリプトの中では、デフォルトの user_compile() 関数は e2fsprogs-1.18.ebuild ファイルのソースよりも前に定義されています。e2fsprogs-1.18.ebuild の中に user_compile() があれば、前に定義されたデフォルト・バージョンを上書きするのです。一方それがなければ、デフォルトの user_compile() 関数が使われます。

これは巧みな業であり、不要な場合には複雑なコードを使わずに、かなりの柔軟性を加えることができたわけです。ここでは扱いませんが、ebuild_unpack() に同じように修正を加えて、ユーザーがデフォルトのアンパック・プロセスをオーバーライドできるようにすることも可能です。そのようにすれば、何らかのパッチを施す必要がある場合や、ファイルが複数アーカイブに含まれている場合に便利です。また、bzip2 で圧縮された tarball をデフォルトで認識するようにアンパック用コードを修正するのも良い考えです。


構成ファイル

ここまでで、巧みな bash 技法の多くを網羅してきましたが、もう一つ付け加えたいと思います。多くの場合、/etc にあるグローバル構成ファイルをプログラムが使うようにすると便利です。幸いにも、bash を使って簡単にそうすることができます。単に、次のファイルを作成し、/etc/ebuild.conf として保管してください。

/ect/ebuild.conf
# /etc/ebuild.conf: set system-wide ebuild options in this file
# MAKEOPTS are options passed to make
MAKEOPTS="-j2"

並行メークとは?

マルチプロセッサー・システムでコンパイルの速度を上げるために、make には、プログラムを並行的にコンパイルするサポートがあります。これは、ソース・ファイルを 1 つずつコンパイルする代わりに、ユーザーが指定した数のソース・ファイルを、make が同時にコンパイルすることを意味します。(ですから、マルチプロセッサー・システムでプロセッサーが余計に使われることになります。) 並行メークは -j # オプションを make に渡すことによって使用可能になります。次のとおりです。

make -j4 MAKE="make -j4"

このコードは 4 つのプログラムを同時にコンパイルするよう、make に指示します。MAKE="make -j4" という引数は、make が立ち上げる子メーク・プロセスに、make が -j4 オプションを渡すように指示します。

この例では、構成オプションを 1 つだけ組み込みましたが、もっと多く組み込んでも構いません。bash の美しい点の一つは、ソースを処理するだけでこのファイルを構文解析できるということです。これはほとんどのインタープリター言語で機能する設計上のトリックです。/etc/ebuild.conf のソースを処理した後、ebuild スクリプトの中に "$MAKEOPTS" が定義されます。ユーザーがオプションを make に渡せるようにするため、それを使用します。通常、このオプションはユーザーが ebuild に、並行メークを実行することを通知するのに使います。

ここに、最終版の ebuild プログラムを示します。

最終版の ebuild プログラム
#!/usr/bin/env bash
if [ $# -ne 2 ]
then
	echo "Please specify ebuild file and unpack, compile or all"
	exit 1
fi
source /etc/ebuild.conf
if [ -z "$DISTDIR" ]
then
	# set DISTDIR to /usr/src/distfiles if not already set
	DISTDIR=/usr/src/distfiles
fi
export DISTDIR
ebuild_unpack() {
	#make sure we're in the right directory	
	cd ${ORIGDIR}
	
	if [ -d ${WORKDIR} ]
	then	
		rm -rf ${WORKDIR}
	fi
	mkdir ${WORKDIR}
	cd ${WORKDIR}
	if [ ! -e ${DISTDIR}/${A} ]
	then
		echo "${DISTDIR}/${A} does not exist.  Please download first."
		exit 1
	fi
	tar xzf ${DISTDIR}/${A}
	echo "Unpacked ${DISTDIR}/${A}."
	#source is now correctly unpacked
}
user_compile() {
	#we're already in ${SRCDIR}
	if [ -e configure ]
	then
		#run configure script if it exists
		./configure --prefix=/usr
	fi
 	#run make
 	make $MAKEOPTS MAKE="make $MAKEOPTS"  
} 
ebuild_compile() {
	if [ ! -d "${SRCDIR}" ]
	then
		echo "${SRCDIR} does not exist -- please unpack first."
		exit 1
	fi
 	#make sure we're in the right directory	 
	cd ${SRCDIR}
	user_compile
}
export ORIGDIR=`pwd`
export WORKDIR=${ORIGDIR}/work
if [ -e "$1" ]
then
	source $1
else
	echo "Ebuild file $1 not found."
	exit 1
fi
export SRCDIR=${WORKDIR}/${P}
case "${2}" in
	unpack)
		ebuild_unpack
		;;
	compile)
		ebuild_compile
		;;
	all)
		ebuild_unpack
		ebuild_compile
		;;
	*)
		echo "Please specify unpack, compile or all as the second arg"
		exit 1
		;;
esac

/etc/ebuild.conf がファイルの最初の方でソース処理されていることに注目できます。また、デフォルトの user_compile() 関数で "$MAKEOPTS" を使用することにも注目できます。これがどのように機能するのか不思議に思われるかもしれません。結局のところ、/etc/ebuild.conf をソース処理する前に "$MAKEOPTS" を参照しますが、実際には /etc/ebuild.conf がはじめに "$MAKEOPTS" を定義しているのです。幸いなことに、変数展開が生じるのは user_compile() の実行時だけなので、これで差し支えありません。user_compile() が実行されるときまでには、/etc/ebuild.conf はすでにソース処理されており、"$MAKEOPTS" は正しい値に設定されています。


まとめ

この記事では bash プログラミング手法の多くを網羅しましたが、これでも bash の持つパワーのほんの表面に触れただけにすぎません。たとえば、製品版の Gentoo Linux ebuild システムは、各パッケージを自動的にアンパックしてコンパイルするだけでなく、以下のことも行えます。

  • ソースが "$DISTDIR" に見つからなければ、ソースを自動的にダウンロードする
  • MD5 メッセージ・ダイジェストを使用して、ソースが破壊されていないか検査する
  • 要求があれば、コンパイル済みアプリケーションをライブ・ファイルシステムにインストールしながら、すべてのインストール・ファイルを記録する (後日簡単にパッケージをアンインストールできるようにするため)
  • 要求があれば、コンパイル済みアプリケーションを好みの方式で tarball にパッケージ化する。そうすれば、後日別のコンピューターにインストールしたり、配布 CD を作成している場合には CD ベースのインストール・プロセスで使用することができる。

加えて、製品版の ebuild システムには他にもいくつかのグローバル構成オプションがあり、コンパイル中にどの最適化フラグを使うか、また GNOME やスラングなどのパッケージ用の任意選択サポートを (それらをサポートするパッケージで) デフォルトで使用可能にするかどうか、といったオプションをユーザーが指定できるようになっています。

このシリーズの記事で触れた他の何よりも、bash がはるかに多くを成し遂げられることは明らかです。読者がこの驚くべきツールについて多くを学び、開発プロジェクトのスピードアップと機能強化のために bash を使うよう刺激を受けられたことを希望しています。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=287113
ArticleTitle=bash 例解: 第 3 回 ebuild システムの探訪
publish-date=05012000