Go to the first, previous, next, last section, table of contents.


@acronym{GNU}ビルドシステム

Autoconfは重要な問題を解決します -- それはシステム特有の,ビルドと実 行時に見つけた信頼できる情報になります -- しかし,これは移植性のある ソフトウエアを開発するためのパズルの一つの部品に過ぎません.このために, @acronym{GNU}プロジェクトは,Autoconfが開始した仕事を完了するためのユー ティリティの,統合された組み合わせ(スイート)を開発してきました. @acronym{GNU}ビルドシステムの最も重要な構成要素は,Autoconf,Automake, そしてLibtool です.この章で,我々はこれらのツールを紹介し,より多くの 情報源を提示し,そして,ソフトウェアに対して@acronym{GNU}ビルドシステ ム全体を便利に使用するように説得してみたいと思います.

Automake

@command{make}の偏在とは,`Makefile'はソフトウェアの自動的なビル ドルールを配布するほとんど唯一の現実的な方法だということを意味している のですが,すぐに@command{make}の多くの限界にぶつかります.それには,自 動的な依存性の追跡に対するサポート,サブディレクトリでの再帰的なビルド, (例えば,ネットワークファイルシステムに対する)信頼できるタイムスタンプ などが足りないので,開発者はそれぞれのプロジェクトに対し,辛い(そして 間違うことが多い)車輪の再開発が必要になっています.多くのシステムの @command{make}の癖のために,移植性は些細な問題ではなくなっています.な によりも,ユーザが期待する多くの標準的なターゲット(make installmake distcleanmake uninstallなど)を手作業で実装する必 要があることがあげられます.もちろん,Autoconfを使用しているので, @CC@@CFLAGS@,そして@command{configure}で提供され るその他の置換式を認識するように,Makefile.inに対応するコードを 挿入しているでしょう.この乱雑な状況はAutomakeで処理しましょう.

Automakeは,プレーンのMakefileの方法と比較して,非常に簡単でよ り強力な構文で,ビルドが必要とするものをMakefile.amファイルで指 定することを可能とし,Autoconfで使用するための移植性の高い Makefile.inを生成します.例えば,単純な"Hello world"プログラ ムをビルドしインストールするためのMakefile.amは以下のようになり ます.

bin_PROGRAMS = hello
hello_SOURCES = hello.c

結果として得られるMakefile.in(約400行)は,自動的に,すべての標 準的なターゲット,Autoconfが提供する置換式,自動的な依存性追跡, VPATHのビルドなどをサポートします.@command{make}でhello プログラムをビルドし,make installでそれを `/usr/local/bin'(または`/usr/local'でないときは @command{configure}で与えたプレフィクス)にインストールします.

Automakeは,開発者のマシンに追加のツールがあることを要求するか もしれません.例えば,開発者が作業しているMakefile.inは移植性が ないかもしれません(例えば,自動的に依存情報を生成するために,コンパイ ラの特殊な機能を使用しているかもしれません).しかし,`make dist' を実行することで,あらゆるシステムで動作するMakefile.inを用いて いる,`hello-1.0.tar.gz'(やあらゆるプログラムをバージョンを持つ) パッケージを生成します.

Automakeの利点は,パッケージが大きければ大きい(特にサブディレクトリが あるもの)ほど有利になりますが,小さなプログラムに対しても重要な利便性 と移植性を追加します.そして,それだけがすべてではありません@enddots{}

Libtool

他のプログラムでも,これまでの作業の成果から利益を得ることを可能にする ため,プログラムだけでなくライブラリをビルドしたいことも頻繁にあるでしょ う.理想的には,共有(動的にリンクされる)ライブラリを生成したい と考え,それは,複数のプログラムからディスクやメモリに同じものを複製せ ずに使用することが可能で,リンクされているプログラムに依存せずに更新可 能だからです.しかし,移植性の高い共有ライブラリは悪夢の元です -- そ れぞれのシステムは,独自の互換性のないツール,コンパイラフラグ,そして 魔法の呪文があります.幸いにも@acronym{GNU}は解決方法を提供しています. それは,Libtoolです.

Libtoolは,共有ライブラリのビルドに関するすべての要求を処理し,現時点 では,移植性を扱うための唯一の方法だと思われます.また,以下の ような頭痛の種も扱います.それは,共有ライブラリの様々な接尾子を扱う Makefileルールの相互作用,以前にスーパーユーザによってインストー ルされた共有ライブラリとの信頼できるリンク,そして,整合性の高いバージョ ン管理システムの提供です(それは,ライブラリの異なるバージョンを,バイ ナリ互換性を壊さないようにインストールし更新することを可能にするための ものです).しかしLibtoolは,Autoconf同様に,単独で使用することは不可能 で,それは単純にAutomakeと組み合わせて利用されます -- そこで,Libtool は共有ライブラリが必要なときに自動的に使用され,そして使用者はその構文 を知っている必要はありません.

参考文献

単一のシステムでの小さなプロジェクトに対して,簡単な@command{make}を使 用している開発者は,AutomakeとAutoconfを使用するために学習する見通しを 立てると圧倒されるかもしれません.しかし,ソフトウェアはより多くのユー ザに配布されるので,@acronym{GNU}ビルドツールが提供するサービスを再発 明するために多くの努力を費やしていることと,一度犯して解決した過ちを繰 り返していることがすぐに分かるでしょう.(また,既にAutoconfを学んでい るので,Automakeは朝飯前でしょう.)

@acronym{GNU}ビルドツールの詳細な情報を得るために,訪問する場所はたく さんあります.


Go to the first, previous, next, last section, table of contents.