Autoconf
作者 デビッド・マッケンジー
開発元 GNUプロジェクト
初版 1991
最新版
2.72[1] ウィキデータを編集 / 2023年12月22日 (13か月前)
リポジトリ
ウィキデータを編集
プログラミング
言語		 Perl
対応OS クロスプラットフォーム
種別 プログラミングツール
ライセンス GNU GPL
公式サイト www.gnu.org/software/autoconf/
テンプレートを表示

GNU Autoconfは、コードベースを生成するファイルや、生成されたファイルのパッケージ化またはインストールを行うファイルを生成するconfigureスクリプト（英語版）を作成するソフトウェア開発ツールである。Autoconfは、Automake、Libtool、Autoheaderなどのツールとともに、GNU Build System の一部を成している。

Autoconfは、ビルドするコードベースのプログラミング言語に依存しないが、主にC言語、C++、Fortran、Erlang、Objective-Cで使用される。

configureスクリプトは、特定のターゲットシステムにインストールするためのソフトウェアパッケージを構成する。ターゲットシステムで一連のテストを実行した後、configureスクリプトはテンプレートからヘッダファイルとMakefileを生成し、ターゲットシステム用にソフトウェアパッケージをカスタマイズする。

使用方法の概要

AutoconfとAutomakeのフローチャート。Autoconfの初期バージョンでは、「configure.ac」というファイルは「configure.in」という名前であった点に注意が必要である。

開発者は、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コンパイラを検出できる。このアプローチの理論的根拠は、次の利点を得ることである。

Autoconfは、多くのPOSIXシェル構造が古いシェルに移植できないことや、その中のバグについて、詳細なドキュメントを提供している。また、シェル構文のマクロベースの代替であるM4SHも提供している[2]。

動作

Autoconfは、特定のソースコード本体を特徴付けるconfigure.acファイルの内容に基づいてconfigureスクリプトを生成する。configureスクリプトを実行すると、ビルド環境がスキャンされ、下位のconfig.statusスクリプトが生成される。このスクリプトは、他の入力ファイル（最も一般的にはMakefile.in）を、そのビルド環境に適した出力ファイル（Makefile）に変換する。最後に、makeプログラムはMakefileを使用して、ソースコードから実行可能プログラムを生成する。

Autotoolsの複雑さは、ソースコード本体が構築される状況の多様性を反映している。

ファイルを処理するために、Autoconfはm4マクロシステムのGNU実装を使用する。

Autoconfには、C言語ヘッダファイルの管理に役立つautoheader、Autoconfの初期入力ファイルを作成できるautoscan、プログラムで使用されるCプリプロセッサ識別子を一覧表示できるifnamesなどの補助プログラムがいくつか付属している。

批判

Autoconfは時代遅れの技術を使用しており、多くのレガシーな制限があり、configure.acスクリプトの作成者にとって単純なものを不必要に複雑にしているという批判もある。特に、Autoconfの弱点としてよく挙げられるのは次の点である。

これらの制限のため、GNU Build System を使用していたいくつかのプロジェクトは、CMakeやSConsなどの別のビルドシステムに切り替えた[3][9]。

関連項目

脚注

  1. ↑ "autoconf-2.72 released [stable"]; 出版日: 2023年12月22日; 閲覧日: 2023年12月25日.
  2. ↑ “Portable Shell”. Autoconf. 20 January 2020閲覧。
  3. 1 2 Neundorf, Alexander (2006年6月21日). “Why the KDE project switched to CMake -- and how”. 2025年2月6日閲覧。
  4. ↑ Kamp, Poul-Henning (2012-08-15). “A Generation Lost in the Bazaar”. ACM Queue 10 (8): 20–23. doi:10.1145/2346916.2349257.
  5. 1 2 McCall, Andrew (2003年6月21日). “Stop the autoconf insanity! Why we need a new build system”. 2009年7月7日時点のオリジナルよりアーカイブ。2025年2月6日閲覧。
  6. ↑ “GNU Coding Standards”. 2025年2月6日閲覧。
  7. ↑ Kamp, Poul-Henning (2010年4月20日). “Did you call them autocrap tools?”. 2017年9月11日時点のオリジナルよりアーカイブ。2017年8月16日閲覧。
  8. ↑ Dickey, Thomas. “why i still use autoconf 2.13”. 2025年2月6日閲覧。
  9. ↑ “Blender.org - Build systems”. 2008年12月2日時点のオリジナルよりアーカイブ。2009年6月10日閲覧。

外部リンク

⌬ Phoenix Mesh CID: 未登録 IPFS未登録 📡 0ピア N=1 CRITICAL PQS B71