このツールキットの不完全性、CMake / QMakeの優位性、お気に入りのビルドシステムの代用について長い間話すことができますが、autotoolsを使用するプロジェクトはどこでも私たちを取り囲んでいます。その後、開発者にパッチを送信し、自動生成されたファイルを編集しないでください。
また、autoconfはビルドシステムではなく、アセンブリ前の構成システムであることも理解しておく必要があります。 何らかの理由で、autoconfは「15の長いバージョンのFortranコンパイラをチェックし、次にこれらのコンパイラによる主要なサポートをチェックする」怪物と見なされます。 別のことは、多くの人がその設定をプロジェクトからプロジェクトへ単純にコピーアンドペーストするだけで、結果として恐ろしいことです。
この記事（まだサイクルを処理する予定です）では、autoconf、それが必要な理由、およびその使用方法についてお話したいと思います。
注：記事のソースコードを含むアーカイブを準備しました 。 ダウンロードできます 。
POSIX環境の球状プログラムの簡単な例でautoconfが使用される理由を説明するのが最善です。
したがって、構成から行を読み取り、ログに書き込む1つの実行可能ファイルで構成されるプログラムがあるとします。 ペイロードに加えて、非常に多くのプログラムがまさにそれを行うので、これは良い球形の例です。
#include <stdlib.h> #include <stdio.h> void main (int argc, char**argv[]) { FILE* config = fopen ("/etc/hellolog.conf", "r"); FILE* log = fopen ("/var/log/hellolog.log", "a"); char*line; getline (&line, NULL, config); fprintf (log, "Line from config %s", line); fclose(config); fclose(log); free(line); }
そして、それをビルドする簡単なMakefile：
#!/usr/bin/make -f SOURCES = main.c all: hellolog hellolog: $(SOURCES) gcc -o $@ $(SOURCES) clean: rm hellolog .PHONY: all clean
読み込みプロセス中にMakefileについて質問がある場合は、 make dockを読むことを強くお勧めします。
原則として、それを受け取って使用しますが、良い方法では、プログラムもシステムにインストールする必要があります。 実行可能ファイルを/ binにコピーする必要があると推測できますが、インストールとアンインストールの目標を同時に作成することをお勧めします。
install: install hellolog $(DESTDIR)/usr/bin/hellolog uninstall: rm $(DESTDIR)/usr/bin/hellolog
install-* nix-oyユーティリティ。ファイルのコピーに加えて、ファイルへのアクセス権で操作を実行します。
ここではDESTDIRが必要です。これにより、システムに直接ではなく、一時ディレクトリにインストールを実行し、パッケージアセンブリシステムがそこからそれらを読み取ってパッケージ化できるようになります。 make installを直接使用することは非常に悪いことを覚えていますか？
1つの重要な問題が残っています-ハードコードのすべての方法。 誰かがホームディレクトリの/ opt /にプログラムをインストールする必要がある場合、またはディストリビューションが使用されている場合、FHSでくしゃみをしたかったので、問題が発生します。
原則として、DESTDIRと同様に、必要なディレクトリへのパスを引数として取ることができます（makeはMakefileで指定された値をオーバーライドするため、デフォルトを作成することもできます。まず、ソースコードを変更します。
... #define CONFIG_PATH CONFDIR"/hellolog.conf" #define LOG_PATH LOCALSTATEDIR"/helloconf.log" void main (int argc, char**argv[]) { printf ("Config %s Log %s\n", CONFIG_PATH, LOG_PATH); FILE* config = fopen (CONFIG_PATH, "r"); FILE* log = fopen (LOG_PATH, "a"); ...
次に、必要なパスの定義をMakefileに追加し、途中でCFLAGSに渡します。これにより、コンパイル時にいくつかのファイルを再利用しやすくなり、インストールとアンインストールの目標も変更します。
#!/usr/bin/make -f SOURCES = main.c prefix = /usr/local bindir = $(prefix)/bin sysconfdir = $(prefix)/etc sharedstatedir = $(prefix)/var CFLAGS = -DCONFDIR='"$(sysconfdir)"' -DLOCALSTATEDIR='"$(sharedstatedir)"' all: hellolog hellolog: $(SOURCES) gcc $(CFLAGS) -o $@ $(SOURCES) clean: rm hellolog install: install hellolog $(DESTDIR)$(bindir)/hellolog uninstall: rm $(DESTDIR)$(bindir)/hellolog .PHONY: all clean install uninstall
すでにはるかに優れています。 make prefix = / opt / hellolog && make install prefix = / opt / hellologを実行し、このディレクトリ内のプログラムファイルを分離できます。 現在の問題は、より多くのアセンブリの目標が存在する可能性があることであり、毎回大量のパラメーターを記述することはあまり便利ではありません。 良い方法では、構成パラメーターを受け取る構成スクリプトにすべてを取り出す必要があり、将来はmakeを使用するだけです。
ひげを生やした時代には、そのようなスクリプトはコードの移植性の目的で同時に手動で作成されました（ここではPOSIXのみを使用しますが、これらのプログラムにはまだ多くのライブラリがあり、一部は互換性があります）、Makefileロジックへの依存関係チェックとプラットフォーム依存の変更が含まれていました。 ある時点で、コピーペーストと呼ばれる高度な中国のコード再利用手法によってプロジェクトからプロジェクトに転送されたスクリプトコードの量が、想像できる制限を超え始めました。 その結果、1人の機知に富んだ人が、M4のマクロ（M + 4文字のマクロ、KerniganとRitchieによって開発されたマクロ言語）に頻繁に使用される部分を入れて、autoconfを作成することにしました。 後に非常に普及し、その後、インフラストラクチャ上でautomakeおよびlibtoolツールが作成されました。 それにもかかわらず、autoconfの本質は同じままで（マクロのセット）、個別に正常に使用できます。
おもちゃプログラムで何ができるか見てみましょう。 原則として、一連の変更は非常に小さく、Makefileにのみ適用されます。 定義済みのパス値をプレースホルダーに置き換え、Makefile自体の名前をMakefile.inに変更します。
prefix = @prefix@ exec_prefix = @exec_prefix@ bindir = @bindir@ sysconfdir = @sysconfdir@ sharedstatedir = @sharedstatedir@
また、最小限の有用なconfigure.ac構成ファイルも追加します。
AC_INIT([hellolog], [1.0]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT
autoreconfを実行し、現在のディレクトリにある構成ファイルを取得します。このファイルには、すべてのユーザー向けの通常のコマンドライン形式があります。 ./configure --prefix = / opt && make && ./hellologを実行し、すべてのパスのスペルが正しいことを確認します。 それでは、「フードの下」で何が起こったのか見てみましょう。
autoconfが受け入れる唯一のファイルはconfigure.acです。これは、マクロを使用する通常のBourneシェルスクリプトです。AC_INITとAC_OUTPUTはそれぞれ必要なスケルトンであり、AC_CONFIG_FILESは、置き換える必要があるファイルのリストを示します。 ここでは、依存関係のチェックなど、さまざまなアクションを実行できます。 このためにpkg-configを使用することをお勧めします。別のマクロセットがあります。 次に、Bourne互換のシェルとawk（以前はsedが使用されていた）のみを必要とする構成スクリプトが生成されます。
./configureは、チェック後、必要な置換パラメーターを含むconfig.statusスクリプトを生成して実行します。 そして、これらの置換の値を持つファイルを生成します。 したがって、Makefileのみを変更した場合は、config.statusを実行するだけです。
全体として、ツールチェーンは次のようになります：autoreconf + configure.ac-> configure-> config.status-> summary files。
基本的に、お気に入りのビルド環境でautoconfを使用することを妨げるものは何もありません。 たとえば、MonoでシャープにしたプログラムにMSBuildを使用すると、Makefileラッパーは簡単です。
参照資料
GNU Makeマニュアル
M4マニュアル
Autoconfマニュアル （英語）
注釈
1. die（「di」と読む）は、ドイツ語の複数形の決定的な冠詞です。