Loading article…
GNU Autotools （ GNU Build Systemとも呼ばれる）は、ソースコードのビルドと生成されたバイナリのパッケージ化をサポートするために設計されたビルド自動化ツール群です。コードをカスタマイズしたり変更したりすることなく、複数のターゲットシステム向けにコードベースをビルドできます。多くのLinuxディストリビューションおよびUnix系環境で利用可能です。
Autotools はGNU ツールチェーンの一部であり、多くのフリーソフトウェアやオープンソースパッケージで広く使用されています。そのコンポーネントツールはフリーソフトウェアであり、特別なライセンス例外[ 1 ] [ 2 ]によりプロプライエタリソフトウェアでの使用が許可されているGNU General Public Licenseの下でライセンスされています。
ソフトウェアプログラムの移植性を確保するのは難しい場合があります。コンパイラはシステムごとに異なり、一部のシステムでは特定のライブラリ関数が欠落している場合もあります。コンパイラファイル（Cヘッダーなど）の名前が異なる場合もあります。共有ライブラリのコンパイル方法やインストール方法も異なる場合があります。プラットフォームの違いに対処する一つの方法は、条件付きコンパイルコード（つまり、#ifdef）を作成することですが、ビルド環境の種類が非常に多いため、この方法はすぐに管理不能になります。Autotoolsは、この問題をより管理しやすくするために設計されています。
Autotools は、GNUユーティリティのAutoconf、Automake、およびLibtoolで構成されています。[ 3 ]その他の関連ツールには、GNU make、GNU gettext、pkg-config、およびGNU Compiler Collection (GCC) があります。
Autotools は、比較的幅広いユーザー コミュニティとクロス プラットフォームソフトウェアを共有するのを支援します。比較的堅牢なクロス プラットフォーム ビルド サポートを提供することでソース コードの共有を容易にし、ユーザーがソフトウェアを自分でビルドできるようにします。一般的に、ソース コードは、Bourne 互換シェル以外の依存関係を持たないconfigureという名前のスクリプトとともに配布されます。Autotools が利用可能である必要はありません。ユーザーは、を実行すると、 Makefile を含むさまざまなファイルが生成され、ユーザーはそれを使用してを実行します。[ 4 ] [ 5 ]configuremake
Autotoolsは、ビルドマシン上でネイティブプログラムをビルドするためにも、他のアーキテクチャへのクロスコンパイルのためにも使用できます。[ 6 ]
MinGWを使用すれば、Linuxやその他のUnix系ビルドシステムからWindowsホスト上で動作するソフトウェアをクロスコンパイルすることも可能ですが、Bourneシェルスクリプトを単独で実行できないオペレーティングシステム（Microsoft Windowsファミリーなど）では、ネイティブコンパイルが望ましい場合が多くあります。そのため、Bourneシェルを標準コンポーネントとして提供するUnix系システムに比べて、Windowsオペレーティングシステム上でこのようなソフトウェアをビルドするのはやや困難です。ただし、 Windows上にCygwinまたはMSYSシステムをインストールすることで、 Unix系互換レイヤーを提供し、configureスクリプトを実行できるようにすることができます。Cygwinには、GNU Compiler Collection、GNU make 、およびWindows内でほぼ完全なUnix系システムを提供するその他のソフトウェアも含まれています。MSYSにも、GNU makeおよびGCCのMinGWバージョンと連携するように設計されたその他のツールが含まれています。
利用者は、ソースコードを修正する場合などに必要となる設定スクリプトを再生成できます。この場合、Autotoolsがインストールされている必要があります。
autoconf によって生成される configure スクリプトは、さまざまなライブラリ、ヘッダー ファイル、言語機能が存在するかどうかをテストするために、C コンパイラなどのプログラムを複数回実行するため、処理が遅くなることがあります。これは特にCygwinに影響します。Cygwin はネイティブのfork システム コールがないため、 Linuxよりも configure スクリプトの実行がかなり遅くなる可能性があります。[ 7 ]
ACM Queueのコラムで、FreeBSD開発者のPoul-Henning Kamp はGNU ビルドシステムを批判しました: [ 8 ]
このアイデアは、configureスクリプトが約200個の自動テストを実行することで、ユーザーがlibtoolを手動で設定する手間を省くというものです。しかし、これは非常に悪いアイデアであり、1980年代に登場した当時からすでに多くの批判を受けていました。なぜなら、configureスクリプトという見せかけの裏でソースコードが移植可能であるかのように装うことを許し、そもそも移植性という品質を最初から備えていないからです。configureのアイデアが生き残ったことは、まさに嘆かわしいことです。
カンプは、 1980年代の多数のUnix派生版に内在する移植性の問題の中にビルドシステムの歴史を概説し、そのようなビルドシステムが存在する必要性を嘆いている。
libtool の configure の 31,085 行は、<sys/stat.h>と<stdlib.h>が存在するかどうかをチェックしますが、これらのファイルが存在しない Unixen には、libtool を実行するのに十分なメモリも、16 MB のソースコードを格納するのに十分なディスク容量もありませんでした。
Autotools の批判者は、ユーザーにとってよりシンプルな代替手段を頻繁に提唱していますが、これは必ずしも良いことではないと主張する人もいます。Autotools 、第 2 版: GNU Autoconf、Automake、および Libtool の実践ガイドの著者である John Calcote [ 9 ]は、次のように意見を述べています。[ 10 ]
Autotoolsは、実際には他のどのビルドツールよりも透明性が高いと言えます。他のツール（cmake、mavenなど）は、ビルドプロセスの詳細からユーザーを隔離することで、はるかにシンプルであると謳っていますが、これらのツールの主な欠点は、まさにこの隔離によって、ユーザーが独自のプロジェクト固有のビルド目標を達成するために必要な変更を加えることができなくなることです。
cmake、maven、 gradleなど、 この側面について良いことしか言わない人は、デフォルト設定から十分に離れる必要のあるプロジェクトに取り組んだことがないだけです。私はそれらすべてを使ってきましたが、自分の望むこと以外はすべてやってくれるツールの欠点を回避する方法を見つけようと、何時間もイライラしながら費やしてきました。Autotoolsでは、これは全く問題になりません。このスレッドで誰かが先に述べたように、configure.ac ファイルにシェルスクリプトを、Makefile.am ファイルにメイクスクリプトを記述できます。これこそが透明性の真髄です。これほどの柔軟性を備えたツールは他に存在しません。