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.