[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 |
configure
スクリプトの配布 Autoconfが生成した |
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コンソーシアムからのもので,著作権保護はあり
ません.
なぜ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ユーティリティが好きなので,既にインストール しています.
AutoconfがGNU M4を要求し,GNU M4にAutoconfの
|
これは誤解です.GNU M4は,Autoconfが生成した
configure
スクリプトと共に配布されていますが,Autoconfは,スク
リプトを実行するためにGNU M4をインストールすることを要求しませ
ん.AutoconfはM4のconfigure
スクリプトを変更したいときだけ必要
で,(主に管理者以外) ほとんどの人が必要ありません.
なぜ |
何人かがこの質問を扱って書いてきたので,私はここでそれらの説明に脚色しま す.
以下の答えは,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
セットアップにあるものさえ,繰りさえされ ることを意味します.
#define
で定義する方法は? プログラムは,
以下のようになりました.
|
既に説明しているので,この動作は目的通りで,GNU Coding Standardsでも強制されています.インストールディレクトリの変数 を 参照してください.同様の目的を達成するため,いくつかの手段があります.
AC_DEFINE
を使用せず,コンパイルフラグでdatadir
の実際の値を
渡す`Makefile'を使用してください.詳細は,インストールディレクトリの変数を参照してください.
プログラムのコンパイル時では,この解決方法は単純になります.
CPPFLAGS
を拡張してもかまいません.
CPPFLAGS = -DDATADIR=\"$(datadir)\" @CPPFLAGS@ |
または,そのためのヘッダファイルを作成します.
DISTCLEANFILES = datadir.h datadir.h: Makefile echo '#define DATADIR "$(datadir)"' >$@ |
AC_DEFINE
を使用しますが,configure
にdatadir
とそ
の他のリテラル値を計算させます.多くの人々は,ラッパーマクロでこの作業を
自動的に実行させています.例えば,
Autoconf Macro Archive
のマクロAC_DEFINE_DIR
です.
この解決方法は,GNU Coding Standardsに準拠していません.
これまでのすべての解決方法は,これらのディレクトリの絶対パスが,実行形式
に強く結び付いていて,あまり良くないことに注意してください.
prefix
からの相対パスを計算し,実行時にprefix
を見つけてもよ
く,こうするとパッケージが移動可能になります.この問題を解決するために既
に利用可能なマクロもあります.
Autoconf Macro Archive
のadl_COMPUTE_RELATIVE_PATHS
と
adl_COMPUTE_STANDARD_RELATIVE_PATHS
を参照してください.
このディレクトリ`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'がなければ八倍遅くなります.
機能の調査時に覚えておくべき最も重要なガイドラインは,使いたいものをでき
るだけ真似てみるということです.残念ながら,古いバージョンの
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.