Autoconfに関するいくつかの質問が,時々発生します.ここではそれらを扱い ます.
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コンソーシアムからのもので,著作権保護 はありません.
なぜ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}スクリプトを変更したいときだ け必要で,(主に管理者以外) ほとんどの人が必要ありません.
なぜ@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 インストールディレクトリの変数 を参照してください.同様の目的を達成するため,いくつかの手段があります.
AC_DEFINE
を使用せず,コンパイルフラグでdatadir
の実際の値
を渡す`Makefile'を使用してください.詳細は,section インストールディレクトリの変数を参照してください.
CPPFLAGS
を拡張してもかまいません.
CPPFLAGS = -DDATADIR=\"$(datadir)\" @CPPFLAGS@または,そのためのヘッダファイルを作成します.
DISTCLEANFILES = datadir.h datadir.h: Makefile echo '#define DATADIR "$(datadir)"' >$@
AC_DEFINE
を使用しますが,@command{configure}にdatadir
と
その他のリテラル値を計算させます.多くの人々は,ラッパーマクロでこの作
業を自動的に実行させています.例えば,
@href{http://www.gnu.org/software/ac-archive/, Autoconf Macro Archive}
のマクロAC_DEFINE_DIR
です.
この解決方法は,@acronym{GNU} Coding Standardsに準拠していません.
prefix
からの相対パスを計算し,実行時にprefix
を見つけても
よく,こうするとパッケージが移動可能になります.この問題を解決するため
に既に利用可能なマクロもあります.
@href{http://www.gnu.org/software/ac-archive/, Autoconf Macro Archive}
のadl_COMPUTE_RELATIVE_PATHS
と
adl_COMPUTE_STANDARD_RELATIVE_PATHS
を参照してください.
このディレクトリ`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.