次: Defining Directories, 前: Bootstrapping, 上: FAQ
なぜ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セットアップにあるものさえ,繰りさえされ ることを意味します.