GNU オートツール

GNU オートツール

原作者	コミュニティ
開発者	フリーソフトウェア財団
安定リリース	複数
書かれた	M4（コンピュータ言語）、C
オペレーティング·システム	クロスプラットフォーム
プラットフォーム	GNUなど
含まれるもの	GNU オペレーティング システム
利用可能	英語
ライセンス	GNU 一般公衆利用許諾書バージョン 2
Webサイト	www.gnu.org/software/software.html

GNU Autotools は、 GNU Build Systemとも呼ばれ、ソースコードの構築と結果のバイナリのパッケージ化をサポートするように設計されたビルド自動化 ツールのスイートです。コードをカスタマイズまたは変更することなく、複数のターゲットシステム用のコードベースの構築をサポートします。多くのLinux ディストリビューションとUnix のような環境で利用できます。

AutotoolsはGNUツールチェーンの一部であり、多くのフリーソフトウェアやオープンソースパッケージで広く使用されています。そのコンポーネントツールはフリーソフトウェアであり、GNU一般公衆利用許諾書の下でライセンスされていますが、特別なライセンス例外^{[1] [2]により、}プロプライエタリソフトウェアでの使用が許可されています。

ソフトウェア プログラムを移植可能にするのは難しい場合があります。コンパイラはシステムによって異なります。一部のシステムでは特定のライブラリ関数が欠落しています。コンパイラ ファイル (C ヘッダーなど) の名前が異なる場合があります。共有ライブラリは、さまざまな方法でコンパイルおよびインストールされる可能性があります。プラットフォームの違いを処理する 1 つの方法は、条件付きでコンパイルされたコード (つまり 経由#ifdef) を作成することですが、ビルド環境が多種多様であるため、この方法はすぐに管理不能になります。Autotools は、この問題をより管理しやすい方法で解決するように設計されています。

AutotoolsはGNUユーティリティAutoconf、Automake、Libtoolで構成されています。^[3]その他の関連ツールにはGNU make、GNU gettext、pkg-config、GNUコンパイラコレクション（GCC）などがあります。

Autotools は、比較的幅広いユーザーコミュニティでクロスプラットフォームソフトウェアを共有することを支援する。比較的堅牢なクロスプラットフォームビルドサポートを提供することでソースコードの共有を容易にし、消費者が自分でソフトウェアをビルドできるようにする。通常、ソースコードはconfigureというスクリプトとともに配布される。このスクリプトはBourne 互換シェル以外の依存関係を持たない。Autotools が利用可能である必要はない。消費者は を実行し、消費者が を実行して使用するMakefileを含むさまざまなファイルを生成する。^{[4] [5]} configuremake

Autotoolsは、ビルドマシン上でネイティブプログラムをビルドする場合と、他のアーキテクチャへのクロスコンパイルの両方に使用できます。^[6]

MinGW を使用すれば、Linux やその他の Unix ライクなビルド システムから Windows ホスト上で実行するためのソフトウェアをクロスコンパイルすることも可能ですが、Bourne シェル スクリプトを単独で実行できないオペレーティング システム ( Microsoft Windowsファミリのシステムなど) ではネイティブ コンパイルが望ましい場合が多くあります。このため、Windows オペレーティング システム上でそのようなソフトウェアを構築するのは、Bourne シェルを標準コンポーネントとして提供するUnix ライクなシステム上よりも少し難しくなります。ただし、Windows 上にCygwinまたはMSYSシステムをインストールしてUnix ライクな 互換性レイヤーを提供し、configureスクリプトを実行できるようにすることができます。Cygwin は、GNU コンパイラ コレクション、GNU make 、および Windows 内でほぼ完全な Unix ライクなシステムを提供するその他のソフトウェアも提供しています。MSYS は、GCC のMinGWバージョンで動作するように設計された GNU make およびその他のツールも提供しています。

消費者は、ソース コードを修正する場合に必要になる可能性のある configure スクリプトを再生成できます。この場合、Autotools がインストールされている必要があります。

autoconfによって生成されたconfigureスクリプトは、Cコンパイラなどのプログラムを複数回実行して、さまざまなライブラリ、ヘッダーファイル、言語機能が存在するかどうかをテストするため、遅くなる可能性があります。これは特にCygwinに影響します。Cygwinにはネイティブのforkシステムコールがないため、 Linuxよりもconfigureスクリプトの実行がかなり遅くなる可能性があります。^[7]

FreeBSD開発者のPoul -Henning KampはACM QueueのコラムでGNUビルドシステムを批判した。^[8]

アイデアは、configure スクリプトが約 200 の自動テストを実行し、ユーザーが libtool を手動で構成する負担を負わないようにすることです。これはひどく悪いアイデアで、1980 年代に登場したときにすでに多くの批判を受けていました。これは、ソース コードが実際には移植性を備えているのではなく、configure スクリプトの見せかけの背後で移植可能であるように見せかけることができるためです。configure のアイデアが生き残ったのは悲劇です。

Kamp 氏は、 1980 年代の多数の Unix バリアントに固有の移植性の問題におけるビルド システムの歴史を概説し、そのようなビルド システムが存在する必要性を嘆いています。

libtool の 31,085 行の configure は、<sys/stat.h>と<stdlib.h>が存在するかどうかを依然としてチェックしますが、これらが欠如している Unixen には、libtool を実行するための十分なメモリも、16 MB のソース コードを格納するのに十分なディスクもありません。

Autotoolsの批評家は、ユーザーにとってよりシンプルな代替手段を頻繁に提唱しているが、これは必ずしも良いことではないと主張する人もいる。Autotools第2版：GNU Autoconf、Automake、Libtoolの実践ガイド^[9]の著者であるジョン・カルコートは、次のように述べている。^[10]

Autotools は、実際には他のどのビルド ツールよりも透明性が高いです。他のすべてのツール (cmake、maven など) は、ビルド プロセスの基礎となる詳細からユーザーを隔離するため、はるかにシンプルであると主張していますが、これらのツールの主な欠点は、この隔離によって、ユーザーが独自のプロジェクト固有のビルド目標を達成するために必要な変更を加えることができないことです。

cmake、maven、gradle などのこの点について良いことしか言わない人は、単にデフォルトから大きく離れる必要のあるプロジェクトに取り組んだことがないだけです。私はそれらすべてを使ってきましたが、いくつかの「何でもできる」(私が望むこと以外) ツール機能の欠点をどう回避するかを試行錯誤して何時間も費やしました。これは Autotools の問題ではありません。このスレッドで以前に誰かが言っていたように、シェル スクリプトを configure.ac ファイルにドロップし、make スクリプトを Makefile.am ファイルにドロップできます。これはまさに透明性の定義です。このレベルの柔軟性を可能にするツールは他に存在しません。

• ビルド自動化ソフトウェアのリスト

• 公式サイト