トップQs
タイムライン
チャット
視点
Autoconf
configure.ac から configure を生成する ウィキペディアから
Remove ads
GNU Autoconfは、コードベースを生成するファイルや、生成されたファイルのパッケージ化またはインストールを行うファイルを生成するconfigureスクリプトを作成するソフトウェア開発ツールである。Autoconfは、Automake、Libtool、Autoheaderなどのツールとともに、GNU Build System の一部を成している。
Autoconfは、ビルドするコードベースのプログラミング言語に依存しないが、主にC言語、C++、Fortran、Erlang、Objective-Cで使用される。
configureスクリプトは、特定のターゲットシステムにインストールするためのソフトウェアパッケージを構成する。ターゲットシステムで一連のテストを実行した後、configureスクリプトはテンプレートからヘッダファイルとMakefileを生成し、ターゲットシステム用にソフトウェアパッケージをカスタマイズする。
Remove ads
使用方法の概要
開発者は、configure.acというファイルにGNU m4言語で命令のリストを記述することで、configureスクリプトの望ましい動作を指定する。一般的なconfigureスクリプトの命令を記述するために、定義済みのm4マクロのライブラリが用意されている。Autoconfは、configure.acの命令を移植可能なconfigureスクリプトに変換する。ビルドを実行するシステムにはAutoconfがインストールされている必要はない。Autoconfは、通常ソフトウェアに同梱されているconfigureスクリプトをビルドするためにのみ必要である。
歴史
Autoconfは、1991年の夏にデビッド・マッケンジーがフリーソフトウェア財団での作業をサポートするために開発を開始した。その後数年間で、さまざまな作者による機能強化が加わり、移植可能な自由ソフトウェアまたはオープンソースソフトウェアを作成するための最も広く使用されているビルド構成システムとなった。
アプローチ
Autoconf は、Perl で使用される Metaconfig パッケージに似ている。以前 X Window System (X11R6.9 まで) で使用されていた imake システムとは密接に関連しているが、考え方は異なる。
Autoconfの移植性に対するアプローチは、バージョンではなく機能をテストすることである。たとえば、SunOS 4のネイティブCコンパイラはISO Cをサポートしていなかったが、ユーザーまたは管理者がISO C準拠のコンパイラをインストールしている可能性がある。純粋なバージョンベースのアプローチではISO Cコンパイラの存在を検出できないが、機能をテストするアプローチではユーザーがインストールしたISO Cコンパイラを検出できる。このアプローチの理論的根拠は、次の利点を得ることである。
- configureスクリプトは、新しいシステムや未知のシステムでも妥当な結果を得ることができる。
- これにより、システム管理者はマシンをカスタマイズし、configureスクリプトでそのカスタマイズを活用できる。
- 特定の機能がサポートされているかどうかを判断するために、バージョンやパッチ番号などの細かい詳細を追跡する必要はない。
Autoconfは、多くのPOSIXシェル構造が古いシェルに移植できないことや、その中のバグについて、詳細なドキュメントを提供している。また、シェル構文のマクロベースの代替であるM4SHも提供している[2]。
動作
Autoconfは、特定のソースコード本体を特徴付けるconfigure.acファイルの内容に基づいてconfigureスクリプトを生成する。configureスクリプトを実行すると、ビルド環境がスキャンされ、下位のconfig.statusスクリプトが生成される。このスクリプトは、他の入力ファイル（最も一般的にはMakefile.in）を、そのビルド環境に適した出力ファイル（Makefile）に変換する。最後に、makeプログラムはMakefileを使用して、ソースコードから実行可能プログラムを生成する。
Autotoolsの複雑さは、ソースコード本体が構築される状況の多様性を反映している。
- ソースコードファイルが変更された場合は、
makeを再実行するだけで十分である。makeは、変更によって影響を受けるソースコード本体の部分のみを再コンパイルする。 .inファイルが変更された場合は、config.statusとmakeを再実行するだけで十分である。- ソースコード本体が別のコンピュータにコピーされた場合は、
configure（これはconfig.statusを実行する）とmakeを再実行するだけで十分である。（このため、Autotoolsを使用するソースコードは通常、configureが生成するファイルなしで配布される。） - ソースコード本体がより根本的に変更された場合は、
configure.acと.inファイルを変更し、その後のすべての手順も実行する必要がある。
ファイルを処理するために、Autoconfはm4マクロシステムのGNU実装を使用する。
Autoconfには、C言語ヘッダファイルの管理に役立つautoheader、Autoconfの初期入力ファイルを作成できるautoscan、プログラムで使用されるCプリプロセッサ識別子を一覧表示できるifnamesなどの補助プログラムがいくつか付属している。
Remove ads
批判
Autoconfは時代遅れの技術を使用しており、多くのレガシーな制限があり、configure.acスクリプトの作成者にとって単純なものを不必要に複雑にしているという批判もある。特に、Autoconfの弱点としてよく挙げられるのは次の点である。
- 使用されるアーキテクチャの一般的な複雑さ。ほとんどのプロジェクトでは複数の繰り返しが使用される[3][4]。
- Autoconfによって生成されたconfigureスクリプトは、標準化されていない手動のコマンドラインインターフェイスのみを提供すると考える人もいる[5]。一部の開発者が共通の規則を尊重しないのは事実だが、そのような規則は存在し、広く使用されている[6]。
- m4はメジャーな言語ではなく、多くの開発者には知られていない。開発者はAutoconfを非標準のチェックで拡張するためにm4を学ぶ必要がある[5][7]。
- 後方互換性と前方互換性が弱いため、ラッパースクリプトが必要である[8]。
- Autoconfによって生成されたスクリプトは一般的に大きく、かなり複雑である。広範なログが生成されるが、デバッグは依然として困難である。
これらの制限のため、GNU Build System を使用していたいくつかのプロジェクトは、CMakeやSConsなどの別のビルドシステムに切り替えた[3][9]。
Remove ads
関連項目
脚注
外部リンク
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads