GNUのAutotoolsについて学んでいる。

C++の参考書も書かなければならないのだが、今、GNUのAutotoolsについて学んでいる。そもそも、何故必要なのか︵なぜ手でMakefileを書かないのか︶というところから調べている。

GNU Autoconf, Automake and Libtool

Autotools: a practitioner's guide to Autoconf, Automake and Libtool

GNU coding standards - GNU Project - Free Software Foundation (FSF)

今のところの背景事情の理解としては、以下のようなものではないかと思う。

はじめに、makeがあった。makeをとりあえず使うのは簡単だが、すこし高度なことをしようとすると、とたんに難しくなる。そのため、既存のよく書かれたものがプロジェクトからプロジェクトへと流用されていった。

利用者の環境や設定に応じてMakefileの内容を変えたいという状況があったので、しだいに、Makefileを作成するスクリプトが使われるようになった。たいていはbashで書かれたconfigureという名前のスクリプトだった。このスクリプトも、やはり高度なものを正しく書くのは難しいため、やはり既存のよく書かれたものが、プロジェクトからプロジェクトへと流用されていった。

Makefileやconfigureを手で書くのは問題がある。既存の別の目的に書かれたものを流用するのも問題がある。なにか汎用的なものがほしい。ユーザーがちょっとしたマクロを書くだけで、あとは全部生成してくれるような枠組みが欲しい。そんなわけで、1991年にautoconfの開発が始まった。

別の理由としては、makeやbashの実装は多数あり、どれも微妙に挙動が違うため、移植性のあるMakefileやbashスクリプトを書くのが難しい。やはり共通の枠組みが欲しいというのもあったらしい。

また、ソフトウェアをソースコードで配布する文化である以上、ビルドは共通の方法で簡単にできなければならないという事情もあった。そのため、allとかcleanとかinstallのような業界標準のターゲットも決まっていった。そういうのを手作業で全部書くのは面倒だ。

autoconfは、Makefile.inをもとにMakefileを生成する。autoconfはconfigureスクリプトの生成をしてくれるが、Makefile.inは、まだ手で書かなければならなかった。Makefile.inは、Makefileとほぼ変わらない。autoconfはすでに書かれたほぼ完全なMakefileから、Makefileを生成する。そのため、Makefile.inを生成するためのautomakeが開発された。

automakeは、Makefile.amからMakefile.inを生成する。Makefile.amには、簡単なマクロと、必要に応じてその他のmakeのコードを書く。Makefile.inは、configureスクリプトによってMakefileになる。

それから、移植性に優れたshared libraryを書くための枠組みとして、libtoolがある。

どうもUNIXの文化なのだろうか、既存のソフトウェアはそのまま土台として使い、その上により高級な機能を実装するというのは。

makeの機能も含んだ新たなビルドシステムを開発するのではなく、makeはそのままで、Makefileを出力するメタなシステムを開発するとは。

まあ、依存関係とファイルのタイムスタンプによるターゲットの生成ソフトウェアとしてのmakeは、もう完成されたものなので、わざわざ再発明する意味はないのかもしれないが。

結果としてメタメタで理解が難しい。

次は使い方を学ばなければ。