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


Autoconfのよくある質問と答え

Autoconfに関するいくつかの質問が,時々発生します.ここではそれらを扱い ます.

@command{configure}スクリプトの配布

Autoconfが生成した@command{configure}スクリプトの配布の際,制限はあり
ますか?それは,それを利用する私のプログラムに影響しますか?

Autoconfが生成するコンフィギュレーションスクリプトを,配布したり使用し たりすることに制限はありません.Autoconfバージョン1では,@acronym{GNU} General Public Licenseでカバーされていました.我々はソフトウェア著者に, GPLのような規則で成果を配布することを奨励していましたが,Autoconfを使 用するためにそうすることは要求していません.

@command{configure}と一緒に使用するファイルの`config.h.in'は, `configure.ac'に対して使用した著作権に従います.`config.sub'`config.guess'は,Autoconfが生成する@command{configure}スクリプ トと一緒に使用するとき,GPLの例外とされ,他のパッケージと同じ規則で配 布できます.`install-sh'はXコンソーシアムからのもので,著作権保護 はありません.

なぜ@acronym{GNU} M4が必要なのですか?

なぜAutoconfは@acronym{GNU} M4を必要とするのですか?

M4の実装の多くは,マクロのサイズと数にハードコードされた制限があり,マ クロ数はAutoconfの方が多くなっています.それらは,Autoconfのような洗練 されたアプリケーション無しでは難しい,以下を含むいくつかの組み込みマク ロが足りません.

m4_builtin
m4_indir
m4_bpatsubst
__file__
__line__

固まった状態のファイルを使用するので,Autoconfでは@acronym{GNU} M4のバー ジョン1.4以上を要求します.

ソフトウェア管理者はAutoconfを使用する必要があり,@acronym{GNU} M4はコ ンフィグレーションとインストールが簡単なので,@acronym{GNU} M4のインス トールの要求も妥当だと思われます.@acronym{GNU}と他のフリーソフトウェ アの管理者の多くは,@acronym{GNU}ユーティリティが好きなので,既にイン ストールしています.

ブートストラップはどうするのですか?

Autoconfが@acronym{GNU} M4を要求し,@acronym{GNU} M4にAutoconfの
@command{configure}スクリプトがある場合,どうやってブートストラップす
ればよいのでしょうか?鶏と卵の問題みたいですね!

これは誤解です.@acronym{GNU} M4は,Autoconfが生成した @command{configure}スクリプトと共に配布されていますが,Autoconfは,ス クリプトを実行するために@acronym{GNU} M4をインストールすることを要求し ません.AutoconfはM4の@command{configure}スクリプトを変更したいときだ け必要で,(主に管理者以外) ほとんどの人が必要ありません.

なぜImakeではないのですか?

なぜ@command{configure}スクリプトの代わりにImakeを使用しないのですか?

何人かがこの質問を扱って書いてきたので,私はここでそれらの説明に脚色し ます.

以下の答えは,Richard Pixleyが書いたものに基づきます.

Autoconfが生成したスクリプトは,処理するために一度もセットアップされた ことがないマシンでも動作することがよくあります.すなわち,新しいシステ ムに対するコンフィグレーションの推測によってきちんと動作します.Imake ではこれは不可能です.

Imakeは,ホスト特定のデータの共通のデータベースを使用します.データベー スを制御している一つの中央の権威によって,配布物はツールのコレクション として作成されるので,X11に対してはこれは意味があります.

@acronym{GNU}ツールはこの方法でリリースされません.それぞれの @acronym{GNU}ツールには管理者がいて,管理者は世界中に散らばっています. 共通のデータベースを使用することは,管理するときの悪夢となります. Autoconfはこの種のデータベースのように見えますが,実際はそうではありま せん.ホストの依存性をリストアップする代わりに,プログラムが要求するこ とをリストアップします.

@acronym{GNU}スイートをネイティブのツールのコレクションだと見なす場合, 問題は似ています.しかし,@acronym{GNU}開発ツールは,ほとんどのホスト+ ターゲットで,クロスツールとしてコンフィグレーション可能です.これらの コンフィグレーションは,同時にインストールも可能です.それらは,ホスト 間で共有するホスト非依存ファイルもコンフィグレーション可能です.Imake はこれらの問題を扱いません.

Imakeテンプレートは標準化の形式です.@acronym{GNU} coding standardsは, 同じ制限を必然的に課さずに,同じ問題を扱います.

以下はPer Bothnerによって書かれたそれ以上の説明です.

Imakeの利点の一つは,cpp`#include'とマクロのメカニズムを 使用した,大きなMakefilesを簡単に生成することです.しかし,cpp はプログラム不可能です.それは限定されたファシリティと,ループがないと いう制限があります.そしてcppではその環境を検査できません.

これらすべての問題は,cppの代わりにshを使用することで解 決されます.シェルは完全にプログラム可能で,マクロの代入や,他のシェル スクリプトを実行する(あるいは他のもののソースとなる)ことが可能で,環境 変数をも検査可能です.

Paul Eggertはより多く詳述しています.

Autoconfの場合,インストーラは,Imake自身がインストールされていて,う まく動作していることを想定する必要がありません.これは,Imakeに慣れて いる人にとっては,あまり利点とは思わないかもしれません.しかし,多くの ホストでImakeはインストールされておらず,デフォルトのインストールでは うまく動作せず,Imakeにパッケージのインストールを要求すると,それらの ホストでパッケージの受け入れを妨げます.例えば,Imakeテンプレートとコ ンフィグレーションファイルは,正確にホストにインストールされていなかっ たり,Imakeのビルドの手続きは,全てのソースファイルが大きなディレクト リにあると誤解したり,Imakeのコンフィグレーションは,一つのコンパイラ を想定しているのに,パッケージやインストーラが他のものを必要としたり, パッケージが期待するImake と,ホストがサポートするImakeのバージョンが 異なったりする場合があります.これらの問題は,Autoconfの方がはるかに稀 で,それぞれのパッケージは,独自の独立したコンフィグレーションプロセッ サを持ってきます.

また,Imakeは,makeとインストーラのCプリプロセッサの間の予期せ ぬ干渉にもしばしば苦しみます.ここでの基本的な問題は,Cプリプロセッサ が,`Makefile'ではなく,Cプログラムのプリプロセスのためにデザイン されているということです.これは,Autoconfではほとんど問題にならず,そ れは汎用のプリプロセッサM4を使用し,そこでは(インストールする人ではな く) パッケージの著作者が標準的な方法でプリプロセスを行います.

最後はMark Eichinのレポートです.

Imakeは,それほど拡張可能でもありません.Imakeに新しい特徴を加えるため に,独自のプロジェクトテンプレートを供給して,既存の特徴の大部分を繰り 返す必要があります.洗練されたプロジェクトに対してベンダーが供給した Imakeテンプレートを使用することは,効力の供給に失敗することを意味しま す.その理由は,(たとえX11プログラムを使用していなくても) 独自のプロジェ クトが必要とするものを全くサポートしていないからです.

しかし,他の面では.

一つの利点として,Imakeは@command{configure}以上のものを持っています. `Imakefile'は,`Makefile.in'より(同じか,かなり)短い傾向にあ ります.これは修正されています.---しかし,少なくともKerberos V5のツリー に対し,共通の`post.in'`pre.in'を呼び出すため, `Makefile'の一部をツリー全体で修正しました.これは,多くの共通の ものが,通常の@command{configure}セットアップにあるものさえ,繰りさえ されることを意味します.

インストールディレクトリを#defineで定義する方法は?

プログラムは,datadirやそれに似た場所にインストールされているラ
イブラリファイルが必要です.以下を使用した場合です.


AC_DEFINE_UNQUOTED([DATADIR], [$datadir],
                   [Define to the read-only architecture-independent
                    data directory.])
以下のようになりました.
#define DATADIR "${prefix}/share"

既に説明しているので,この動作は目的通りで,@acronym{GNU} Coding Standardsでも強制されています.section インストールディレクトリの変数 を参照してください.同様の目的を達成するため,いくつかの手段があります.

`autom4te.cache'はなんですか?

このディレクトリ`autom4te.cache'は何ですか?削除しても大丈夫です
か?

@acronym{GNU}ビルドシステムでは,`configure.ac'が中心的な役割を果 たし,多くのツールから読み込まれます.@command{autoconf}は `configure'を作成するため,@command{autoheader}は `config.h.in'を作成するため,@command{automake}は `Makefile.in'を作成するため,@command{autoscan}は `configure.ac'が完全であるかを調査するため,@command{autoreconf} はそれらを利用する@acronym{GNU}ビルドシステムの構成物を調査するために 読み込みます."`configure.ac'を読み込む"本当の意味は,それをM4 でコンパイルするということで,複雑な`configure.ac'では,それは非 常に長い処理になり得ます.

これが,直接M4を実行する代わりに,これらすべてのツールが @command{autom4te} (see section @command{autom4te}の呼び出し)を呼び出す理由で,特別 な要求に答えている間,将来実行するために`autom4te.cache'に追加情 報を保存しています.例えば,@command{autoconf}を実行する場合,その影で は@command{autoheader}や@command{automake}などを呼び出すとき, `configure.ac'を再び処理する必要が無いように,@command{autom4te} はそれ以外のツールのための情報を保存しています.速度の向上は30倍ぐらい で,`configure.ac'の大きさにより更に大きくなります.

しかし,それは単純なキャッシュです.削除しても問題ありません.

永久に削除することは可能ですか?

このキャッシュの生成は,`~/.autom4te.cfg'で利用不可能にすることが 可能で,詳細はsection @command{autom4te}のカスタマイズを参照してください.キャッシュ を利用不可能にするとAutoconfのテストスイートが40%遅くなることを覚えて おいてください.それ以外の@acronym{GNU}ビルドシステムの構成物を使用し ている場合,キャッシュはより役に立ちます.例えば,Coreutilsで `autoreconf -f'を実行すると,たとえ@option{--forceを暗黙に 指定していてもキャッシュを完全に利用することができないので}キャッシュ が無ければ二倍遅くなり,@option{--force}がなければ八倍遅くなります.


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