| 原作者 | デビッド・マッケンジー |
|---|---|
| 開発者 | GNU プロジェクト |
| 初回リリース | 1991 |
| 安定リリース | 2.72 [1]
/ 2023年12月22日 |
| リポジトリ |
|
| 書かれた | パール |
| オペレーティング·システム | クロスプラットフォーム |
| タイプ | プログラミングツール |
| ライセンス | GNU GPL |
| Webサイト | www.gnu.org/software/autoconf/ |
GNU Autoconfは、 Bourne シェルが利用可能なコンピュータ システム上でソフトウェアを構築、インストール、パッケージ化するためのconfigure スクリプトを作成するツールです。
Autoconf は使用されるプログラミング言語に依存しませんが、C、C++、Fortran、 Fortran 77 、Erlang、またはObjective-C を使用するプロジェクトでよく使用されます。
configure スクリプトは、特定のターゲット システムにインストールするためのソフトウェア パッケージを構成します。ターゲット システムで一連のテストを実行した後、configure スクリプトはテンプレートからヘッダー ファイルとmakefile を生成し、ターゲット システム用にソフトウェア パッケージをカスタマイズします。Autoconf は、 AutomakeおよびLibtoolとともに、Autoheader などの他のいくつかのツールを含むGNU ビルド システムを形成します。
使用方法の概要

開発者は、"configure.ac" というファイルにGNU m4言語で命令のリストを記述することで、configure スクリプトの望ましい動作を指定します。一般的な configure スクリプトの命令を記述するために、定義済みの m4マクロのライブラリが用意されています。Autoconf は、"configure.ac" の命令を移植可能な configure スクリプトに変換します。ビルドを実行するシステムには Autoconf がインストールされている必要はありません。Autoconf は、通常ソフトウェアに同梱されている configure スクリプトをビルドするためにのみ必要です。
歴史
Autoconf は、1991 年の夏に David Mackenzie がFree Software Foundationでの作業をサポートするために開発を開始しました。その後数年間で、さまざまな作者による機能強化が加わり、移植可能なフリー ソフトウェアやオープン ソース ソフトウェアを作成するための最も広く使用されているビルド構成システムになりました。
アプローチ
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スクリプトの作成者にとって単純なシナリオを不必要に複雑にしているという批判もあります。特に、Autoconf の弱点としてよく挙げられるのは次の点です。
- 使用されるアーキテクチャの一般的な複雑さ、ほとんどのプロジェクトでは複数の繰り返しが使用されます。[3] [4]
- Autoconfによって生成された「configure」スクリプトは、標準化されていない手動駆動のコマンドラインインターフェイスのみを提供すると考える人もいます。[5]一部の開発者が共通の規則を尊重しないのは事実ですが、そのような規則は存在し、広く使用されています。[6]
- m4は珍しく、多くの開発者には知られていない。開発者はAutoconfを非標準のチェックで拡張するためにこれを学ぶ必要がある。[5] [7]
- 後方互換性と前方互換性が弱いため、ラッパースクリプトが必要となる。[8]
- Autoconf によって生成されたスクリプトは通常、大きく、かなり複雑です。広範なログが生成されますが、デバッグは依然として困難です。
これらの制限のため、GNUビルドシステムを使用していたいくつかのプロジェクトは、 CMakeやSConsなどの別のビルドシステムに切り替えました。[3] [9]
参照
- CMake – 代替ビルドシステム
- Meson – もう一つのビルドシステム
- スクリプトを構成する
- GNU ビルドシステム
- pkg-config – パッケージの依存関係の検出
参考文献
- ^ Zachary Weinberg (2023年12月22日). 「autoconf-2.72 リリース [安定版]」 . 2023年12月25日閲覧。
- ^ 「Portable Shell」。Autoconf 。 2020年1月20日閲覧。
- ^ ab Neundorf, Alexander (2006-06-21). 「KDE プロジェクトが CMake に切り替えた理由とその方法」
- ^ Kamp, Poul-Henning (2012-08-15). 「バザールで失われた世代」ACM Queue . 10 (8): 20–23. doi : 10.1145/2346916.2349257 . S2CID 11656592.
- ^ ab McCall, Andrew (2003-06-21). 「autoconf の狂気を止めよう! 新しいビルド システムが必要な理由」
- ^ 「GNU コーディング標準」。
- ^ Kamp, Poul-Henning (2010-04-20). 「それらを autocrap ツールと呼んだのですか?」。2017 年 9 月 11 日時点のオリジナルよりアーカイブ。2017年 8 月 16 日閲覧。
- ^ Dickey, Thomas. 「なぜ私は今でも autoconf 2.13 を使うのか」
- ^ 「Blender.org - ビルドシステム」。2008年12月2日時点のオリジナルよりアーカイブ。2009年6月10日閲覧。
外部リンク
- 公式サイト
- GNU Autoconf マクロ アーカイブ
- Goat Book ホームページ (別名 Autobook) 2010-12-20 にWayback Machineでアーカイブされました
- C++ で Automake と Autoconf を使用する
- Automake および Autoconf で C/C++ ライブラリを使用する。
- Autotoolset ホームページ
- Autotools: Autoconf、Automake、Libtool の実践ガイド
- オートツールの神話破り
