12. Questions About Autoconf

Autoconfに関しては、いくつかの質問が頻繁に出ます。 それらのいくつかにお答えしましょう。

12.1 Distributing configure Scripts

Autoconfが生成したconfigureスクリプトには配布制限はありますか?
configureスクリプトを使うプログラムに影響は?

Autoconfによって生成された設定スクリプトの配布に関しては、 なにも制限がありません。Autoconfバージョン1では、 生成された設定スクリプトもGPLによって保護されていました。 現在でも我々はソフトウェアの作者にGPLのような配布条件で 配布を行うことを推奨しますが、Autoconfを使うからといってそれが 必須なわけではありません。

configureに使われる可能性のあるファイルのうち、 `config.h.in'はあなたが指定した`configure.in'の 著作権表示に従います。`config.h.in'は`configure.in'と、 パブリックドメインのファイル`acconfig.h'から生成されるからです。 `config.sub'と`config.guess'は、Autoconfに生成された configureスクリプトとともに使う場合にはあなたの パッケージの配布条件に従います。これはGPLの例外です。 `install-sh'はXコンソーシアムによるもので、 著作権は放棄されています。

12.2 Why Require GNU m4?

なんでAutoconfはGNU m4を必要とするんですか?

多くのm4の実装では、マクロの大きさや数に決め打ちの制限があって、 Autoconfはそれをオーバしてしまいます。また、いくつかの組み込みマクロが 不足している場合があり、それらのマクロなしではAutoconfのような 洗練されたアプリケーションは記述しづらくなります。たとえばこんな マクロがない場合があります:

builtin
indir
patsubst
__file__
__line__

ソフトウェアの管理者はAutoconfだけを使えばよいし、GNU m4は 設定やインストールが簡単です。このため、GNU m4がインストール されていないといけない、というのは妥当と思われます。 GNUやGNU以外のフリーソフトウェアの管理者にはGNUユーティリティの 多くをインストールしている人がたくさんいます。なぜなら 彼らはGNUユーティリティが気に入っているからです。

12.3 How Can I Bootstrap?

AutoconfがGNU m4を必要としていて、GNU m4パッケージがAutoconfで
生成されたconfigureスクリプトを含んでいたら、どこから仕事をはじめたら
いいんですか? 鶏と卵問題になりませんか?

それは誤解です。 確かに、GNU m4パッケージはAutoconfで生成された configureスクリプトを含んでいます。 しかし、configureスクリプトを実行したり GNU m4パッケージをインストールしたりするのに Autoconfは必要ありません。 Autoconfはm4パッケージに含まれるconfigureスクリプトを 変更したい場合にだけ必要です。 ふつう、そのような変更はごく少数のひと(主にm4パッケージの メインテナ)しか行いません。

12.4 Why Not Imake?

なんでconfigureスクリプトでなしにImakeを使わないのですか?

幾人かのひとがこの質問の答えを書いてくれましたので、 それを翻案して載せたいと思います。

以下の答えはRichard Pixleyの答えをもとにしています:

Autoconfで生成されたスクリプトは、 しばしばパッケージを一度も動かしたことのないマシンでも動作します。 つまり、Autoconfスクリプトは新しいシステムのための設定を類推することが できるのです。 Imakeではこれはできません。

Imakeはホスト依存の情報を得るのに共用のデータベースを使います。 X11の配布はツールの集合でできているので、中央集権的にデータベースを 管理することには意味があります。

しかし、GNUのツールはそのように配布されていません。 各々のGNUツールには個別のmaintainerがいます。 maintainerは世界中に散らばっています。 共用のデータベースを使うと、「データベースの管理」という悪夢が待っています。 Autoconfは共用のデータベースのように見えるかもしれませんが、実際には違います。 Autoconfスクリプトは各ホストへの依存性を記述するのではなく、 プログラムの要求事項を記述しているのです。

GNUツール群を固有のツールの集合としてみるなら、 X11の場合と問題は似ているかもしれません。 でも、GNUの開発ツールはクロス開発にも使えます。 しかも、どんなホストとターゲットの組み合わせについても使えますし、 全ての組み合わせは同時におなじマシンにインストールできます。 さらに、ホスト独立なファイルをマシン間で共有するようにもできます。 Imakeはこの問題に対して解を与えていません。

Imakeのtemplateはある種の標準化です。 GNUのcoding standardは同じ問題について、 Imakeの課する制約をいれることなく解決を与えています。

以下はPer Bothnerによるさらなる解説です:

Imakeの利点として、巨大なMakefileをcppの`#include'と マクロ機構を使って簡単に生成できる、ということがあります。 しかし、cppはプログラマブルではありません。 cppでは限られた条件文しか書けませんし、ループは記述できません。 cppでは実行環境を調べることもできません。

以上の問題点は全て、cppでなしにshを使うことで解決できます。 shellは完全にプログラマブルです。マクロの置換、他のshellスクリプトの 実行(や取り込み)もできますし、実行環境を調べることもできます。

Paul Eggertがさらに詳細を述べています:

Autoconfを使う場合には、パッケージのインストールをするひとは 「Imake自体がきちんとインストールされて正しく動作する」ことを仮定しなくて 済みます。 Imakeに慣れたひとには、これはたいした利点とは思えないかもしれません。 しかし、多くのホストではImakeはインストールされていなかったり、 標準インストールの状態ではうまく動作しなかったりします。 そして、パッケージのインストールにImakeを使うと、 Imakeはパッケージをホストにインストールする際の障害になります。 例えば、Imake templateと設定ファイルがホストに正しく インストールされていないことがあります。 Imakeを使ったインストール手順では、 全てのソースファイルが巨大なdirectory treeに格納されていると 仮定していることがあります。 Imakeの設定ファイルは単一のコンパイラを仮定していて、 それがパッケージをインストールするのに使いたいコンパイラと 違うかもしれません。 パッケージの仮定しているImakeのバージョンと、 実際ホストにインストールされているImakeのバージョンが異なるかもしれません。 Autoconfを使う場合、このような問題は稀です。 パッケージに、独立して動く自動設定処理プログラムが付属しているからです。

Imakeを使っていると、makeとCプリプロセッサの予期していない 動作に悩まされることがよくあります。 CプリプロセッサはCのプログラムを処理するために設計されたもので、 `Makefile'を処理するためのものではありません。 Autoconfを使うなら簡単です。 Autoconfはバックエンドに汎用プリプロセッサm4を使っています。 m4を使うのは、 パッケージの作者がconfigureスクリプトを作成するときです。 つまり、インストールをするときにはプリプロセッサは必要ありません (訳註: この行激しく意訳)。

最後にMark Eichinが言うには:

Imakeには拡張性がありません。 Imakeに新しい機能を加えようとすると、 独自のproject templateを作成しなければなりません。 しかも、そのtemplateには既存のtemplateの大部分をコピーして含めねば なりません。 つまり、洗練された開発プロジェクトでは、 ベンダが提供するtemplateは必要なところをカバーしてくれないので 意味がありません (開発プロジェクトがX11向けなら話は別ですが)。

逆の見方をすると:

Imakeにはひとつだけ、configureに対して有利な点があります。多くの 場合、`Imakefile'は`Makefile.in'よりもずっと短く、冗長性があり ません。これを改善する方法はあります。Kerberos V5では、ツリーじゅうの `Makefile'の先頭と末尾の部分を`post.in'と`pre.in'として共 通化し、`Makefile.in'から`Makefile'を生成するときにこれらを読 み込むようにしました。これは、多くの共通のものが、普通configureセッ トアップにあるものさえ、繰りさえされることを意味します。