[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

17. Autoconfのよくある質問と答え

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

17.1 configureスクリプトの配布   Distributing configure scripts
17.2 なぜGNU M4が必要なのですか？   Why not use the standard M4?
17.3 ブートストラップはどうするのですか？   Autoconf and GNU M4 require each other?
17.4 なぜImakeではないのですか？   Why GNU uses configure instead of Imake
17.5 インストールディレクトリを#defineで定義する方法は？   Passing datadir to program
17.6 `autom4te.cache'はなんですか？   What is it? Can I remove it?
17.7 ヘッダが存在するのにコンパイルされません   Compiler and Preprocessor Disagree

17.1 configureスクリプトの配布

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

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

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

17.2 なぜGNU M4が必要なのですか？

 
なぜAutoconfはGNU M4を必要とするのですか？

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

 
m4_builtin
m4_indir
m4_bpatsubst
__file__
__line__

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

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

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

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

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

17.4 なぜImakeではないのですか？

 
なぜconfigureスクリプトの代わりにImakeを使用しないのですか？

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

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

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

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

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

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

Imakeテンプレートは標準化の形式です．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はconfigure以上のものを持っています． `Imakefile'は，`Makefile.in'より(同じか，かなり)短い傾向にあり ます．これは修正されています．--しかし，少なくともKerberos V5のツリーに 対し，共通の`post.in'と`pre.in'を呼び出すため， `Makefile'の一部をツリー全体で修正しました．これは，多くの共通のも のが，通常のconfigureセットアップにあるものさえ，繰りさえされ ることを意味します．

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

 
プログラムは，datadirやそれに似た場所にインストールされているライ
ブラリファイルが必要です．以下を使用した場合です．
 
AC_DEFINE_UNQUOTED([DATADIR], [$datadir],
                   [Define to the read-only architecture-independent
                    data directory.])


以下のようになりました．
 
#define DATADIR "${prefix}/share"

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

17.6 `autom4te.cache'はなんですか？

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

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

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

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


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

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

17.7 ヘッダが存在するのにコンパイルされません

機能の調査時に覚えておくべき最も重要なガイドラインは，使いたいものをでき るだけ真似てみるということです．残念ながら，古いバージョンの AC_CHECK_HEADERとAC_CHECK_HEADERSはこの考えに従うと失敗し， そして，ヘッダの調査のためコンパイラの代わりにプリプロセッサを呼び出しま す．結果として，ヘッダ間での非互換性はコンフィグレーション時に注目されず， 管理者は結局，この問題を別の場所で処理する必要があります．

Autoconf 2.56では両方の調査を実行するので，コンパイラとプリプロセッサが 受け入れない場合，configure派手に文句を言います．プリプロセッサの 結果を利用するときは，`configure.ac'を修正する時間が管理者に与えら れます．しかし，将来はコンパイラだけ考慮されるでしょう．

以下の例を考えて下さい．

 
$ cat number.h
typedef int number;
$ cat pi.h
const number pi = 3;
$ cat configure.ac
AC_INIT
AC_CHECK_HEADERS(pi.h)
$ autoconf -Wall
$ ./configure
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking pi.h usability... no
checking pi.h presence... yes
configure: WARNING: pi.h: present but cannot be compiled
configure: WARNING: pi.h: check for missing prerequisite headers?
configure: WARNING: pi.h: proceeding with the preprocessor's result
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to bug-autoconf@gnu.org. ##
configure: WARNING:     ## ------------------------------------ ##
checking for pi.h... yes

この状況での正しい方法は，四番目の引数を使用することです(see section 一般的なヘッダの調査)．

 
$ cat configure.ac
AC_INIT
AC_CHECK_HEADERS(number.h pi.h,,,
[[#if HAVE_NUMBER_H
# include <number.h>
#endif
]])
$ autoconf -Wall
$ ./configure
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for number.h... yes
checking for pi.h... yes

必要条件となるヘッダのリストは特定のヘッダの調査．

[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.