新しめの Autotools (Autoconf&Automake) を使ってみよう

Nov 1, 2002 (Last Updated: Dec 25, 2005)
Kinuko YASUDA
slides

変更履歴
Autotools とは
基本ステップ
基本ステップ復習
ソースファイルを書く
autoscan する
configure.in を編集 (1)
configure.in を編集 (2): 先頭定型文
configure.in を編集 (3):プログラムのチェック
configure.in を編集 (4): ライブラリのチェック
configure.in を編集 (5): ヘッダファイルのチェック
configure.in を編集 (6): 関数のチェック
configure.in を編集 (7): その他のチェック
configure.in を編集 (8): ファイルの出力
Makefile.am を作る (1) : 基本
Makefile.am を作る (2) : 例
Makefile.am を作る (3) : 応用例
仕上げと実例

∧ < = >

変更履歴

2005/12/25 aclocal のサブディレクトリ探索に関して誤り(変更?)があったので訂正。libtoolに関する記述を部分的に追加
2005/12/22 最近は "touch NEWS README AUTHORS ChangeLog" しないとautomakeしてもMakefile.inを作ってくれない?
2003/11/28 最近のautomake(1.6くらいから?)では AC_CONFIG_HEADERS を AM_CONFIG_HEADER に変えなくてもいいらしい。
2003/11/10 AM_INIT_AUTOMAKE は(Ver. 1.4 の後半リリースくらいから?) 引数がいらない？記述を変更
2003/10/13 間違い多かったので気づいたの直しました(AC_hogeとAM_hoge, HEADERとHEADERSなど)
2003/10/14 AUX_DIR の記述を一時的に削除。

∧ < = >

Autotools とは

言わずと知れた autoconf, autoheader, automake, libtools などの GNU ツール
何をするもの?
- コンパイルに関係する機種依存環境を動的にチェックし、Makefileやヘッダファイルに自動的に反映してくれる。あともっと高尚な目的があると思うが良くしらない
特徴
- auto と言いつつ微妙に自動ではない
- コンパイルする人にとってはなかなか便利
- コンパイルできないときに書き換えが大変
- 細かいバージョンアップのたびに仕様がどんどん変わるのでついていけない
読みもの
- とりあえずAutobook
  - 邦訳も本で出てる
  - 英語版ならオンラインで読める
  - autotools の使い方と言うより、もっと全般的なプログラミングの掟話
  - 内容はなかなか素晴らしい
  - しかしやっぱり Obsolete
  - 長い
- それからAutoconfのドキュメント (share/docあたりにある)
  - 細かい説明が必要なときはこれ
  - いちおう up-to-date に見える
  - 長い
まだよくわかんないところも多いが、とりあえず新しいバージョンでも一通り使えるようになったのでその説明

∧ < = >

基本ステップ

Autoconf 2.54～2.59 + Automake 1.4～1.9あたりで動かす方法 (記述は更新しているので、古いバージョンではもう動かない部分があるかもしれません)

ソースファイルを書く
- 例えば vi hello.c とかしてさくっと書いてみる
autoscan する
- configure.in (最近はconfigure.ac？) の雛型ファイルconfigure.scanを生成してくれる
- mv configure.scan configure.in しましょう
configure.inを編集
- そのままではいろいろ問題があるので直したり必要な行を足したりする
  - AC_INIT(PACKAGE-NAME, VERSION, BUG-REPORT)を適当に変更。
    AC_INIT(hello, 0.1, kinuko@spa.is.uec.ac.jp)とか。
  - automake を使うならAM_で始まるマクロを足す
    1. AC_INITの下あたりに以下の行を追加。
      AM_INIT_AUTOMAKE
    2. (＊古いバージョンのautomakeの場合のみ) AC_CONFIG_HEADER([config.h])を AM_CONFIG_HEADER(config.h)に変更
    3. AC_CONFIG_FILES([])を AC_CONFIG_FILES([Makefile])に変更
      (Makefile.am を先に作っておけばこの変更は不要)
automake用にMakefile.amを作る
- 今回みたいな単純なものはこれだけ書けばOK
```
bin_PROGRAMS = hello
hello_SOURCES = hello.c
```
仕上げ
- touch NEWS README AUTHORS ChangeLog で必要ファイルを作成
- aclocal; autoheader; automake -a -c; autoconf で準備完了
- その後にconfigure.inを書き換えた場合、最近のバージョンでは単にautoreconf -i とすれば良い

∧ < = >

基本ステップ復習

自動的に作られるもの
- autoscanが現在のディレクトリの中身から configure.scanを作る
- aclocalが*.m4とconfigure.inから aclocal.m4を作る
- autoheaderがconfigure.inからconfig.h.inを作る
- automakeがMakefile.amからMakefile.inを作る
- autoconfがconfigure.inからconfigureを作る
- そして、コンパイル時にconfigureとすると Makefile.inからMakefile、 config.h.inからconfig.hなど make に必要なものを自動生成してくれる
作らなければいけないもの
- autoconf のためにconfigure.in
- automake のためにMakefile.am
- その他、configureのために m4マクロを書いておいたりできる。 (acinclude.m4 という名前のファイルに書くと aclocalが自動的に読み込んでくれる)

∧ < = >

ソースファイルを書く

ディレクトリ構造がもっと複雑な場合
- 例えば
  - hello.c は src ディレクトリの下に
  - 他にlibとかdocとか作るかも
- ふつうに作業
```
# mkdir src 
# vi src/hello.c
```
サブディレクトリをつくった場合、トップレベルの Makefile.am で次のように書く
```
SUBDIRS = src
```
srcの下にも Makefile.am が必要

∧ < = >

autoscan する

configure.scanが作られる。
最初はconfigure.inにリネーム(あるいはコピー)して使う
その後もたまにやってconfigure.inと比べてみるといいかも

∧ < = >

configure.in を編集 (1)

configure.in とは?
- configureスクリプトの元となるファイル
- m4マクロとシェルスクリプトからなる。
- autoconf, automake 用のマクロの他、独自定義のm4マクロを使える。例えばgtk/glib用のパスをチェックするm4マクロ (例: gimpのソースから借用)を acinclude.m4 という名前で置いておけば、 configure.in の中でそのマクロを使える使用例 (もしくは、gtk.m4 などの名前で置いてあるディレクトリを aclocal 時に aclocal -I dir として指定する)
- configure.in (configure)でいろいろなヘッダやライブラリ、プログラムのチェックを行い、必要なインクルードファイルやライブラリなどを変数として定義しておけば、コンパイル時に Makefile や config.h にそれを反映させることが出来る。
書き方について諸注意
- 変数の使い方はBシェルと一緒。 VARNAME=value で定義、$VARNAME で参照。
- m4マクロでは `[' と `]' でクオーティングが行われる。マクロの引数が単純な文字列でない場合 (特殊文字があったり他のマクロを引数として渡したりしてる場合)、なるべく `[' と `]' で括ったほうが良い。例えば、
```
AC_CHECK_HEADER([stdio.h], [AC_DEFINE(HAVE_STDIO_H)], 
 [AC_MSG_ERROR([Sorry, can't do anything for you])])    #これはOK
AC_CHECK_HEADER(stdio.h, [AC_DEFINE(HAVE_STDIO_H)], 
 [AC_MSG_ERROR([Sorry, can't do anything for you])])    #これもOK
AC_CHECK_HEADER(stdio.h, AC_DEFINE(HAVE_STDIO_H), 
     AC_MSG_ERROR([Sorry, can't do anything for you]))  #これは危険
```
- m4マクロは引数にシェルスクリプトを取らせることが多いが、複数の文を実行させたい場合も引数中で ';' を使ってはダメ。単に空白で区切るか改行で区切る。例えば、
```
AC_CHECK_HEADER(elf.h, [AC_DEFINE(SVR4) LIBS="$LIBS -lelf"]) #これはOK
AC_CHECK_HEADER(elf.h, [AC_DEFINE(SVR4); LIBS="$LIBS -lelf"]) #これはダメ
```
- コメントは dnl で始める…といいつつ最近のは # でも大丈夫です。

∧ < = >

configure.in を編集 (2): 先頭定型文

以下、概ね configure.in で書かなければならない順番にどんなマクロが使えるのかを紹介。ちなみに[, ]で括られてるものは省略できる引数。 (例の中の`[' と `]'はm4クオートなので注意)

AC_INIT(package-name, version, [bug-report], [tarname])
- 必ず先頭になければいけない。
- 雛形を autoscan が吐いてくれるので、パッケージ名、バージョン名、バグ連絡先(メールアドレスなど)を適当に書き換えるといいでしょう。
- AC_INIT によって以下の変数が自動的に定義される。
  - PACKAGE_NAME … パッケージ名。AC_INITの第1引数
  - PACKAGE_VERSION … バージョン名。AC_INITの第2引数
  - PACKAGE_BUGREPORT … バグレポート時の連絡先。 AC_INITの第3引数 (optional)
  - PACKAGE_TARNAME … tarファイル名。AC_INITの第4引数 (optional)
  - PACKAGE_STRING … 'package version'文字列
  これらの変数は config.h をインクルードすることでソースから参照可能。あるいは、Makefile.am 中で @PACKAGE_NAME@ のようにして参照可能
AM_INIT_AUTOMAKE
- automake を使う場合に必要。 AC_INIT(...)の後に AM_INIT_AUTOMAKEと書いておけば良し
AC_PREREQ(autoconf-version)
- 依存するautoconfバージョンがあれば書く
- 例えばAC_PREREQ(2.54)とか

∧ < = >

configure.in を編集 (3):プログラムのチェック

定番プログラムのチェック (awk, cc, cpp, egrep, fgrep, install, lex, ln -s, ranlib, yacc, など)
- AC_PROG_CC、 AC_PROG_INSTALL、AC_PROG_LN_Sなど、プログラムprognameをチェックするための AC_PROG_prognameというマクロがいくつか既定で用意されている
- 該当するプログラムがあれば CC, INSTALL, LN_S などの変数がそれぞれ定義され、プログラム名を直接使う変わりにその変数を使うことができる (例えば Makefile.am の中で @LN_S@ のように参照できる)
AC_CHECK_PROG(variable, prog-to-check, value-if-found, [value-if-not-found], [path], [reject]))
- サーチパスpath内からプログラムprog-to-checkをチェックする
- pathを指定しなければ$PATHが使われる
- pathの指定は:で区切って複数OK
- 見つかれば変数variableにvalue-if-foundが、見つからなければvalue-if-not-foundが定義される
AC_CHECK_PROGS(variable, progs-to-check, [value-if-not-found], [path])
- 空白で区切られた複数のプログラムprogs-to-checkのうちどれか1つが見つかるまで path内(指定してなければ$PATH内)をチェックする
- 見つかれば見つかったプログラム名が変数variableに定義される

∧ < = >

configure.in を編集 (4): ライブラリのチェック

AC_CHECK_LIB(library, function, [action-if-found], [action-if-not-found], [other-libraries])
- 例えば AC_CHECK_LIB(socket, socket) など
- 該当するライブラリが見つかれば変数$LIBS に -llibrary が追加され、さらに変数HAVE_LIBLIBRARY が定義される。
- action-if-foundなどを独自に指定してる場合、見つかればaction-if-foundが、見つからなければaction-if-not-foundが実行されるちなみにaction-if-[not-]foundで指定できるのはシェルスクリプト(m4マクロでもよい)。
- action-if-not-found のところに AC_MSG_ERROR(Test for library lib failed.) などと書いておけば、ライブラリがなければ configure 中に該当メッセージを出して失敗する。例えば
```
AC_CHECK_LIB(socket, socket, 
       [AC_DEFINE(HAVE_SOCKET)], 
       [AC_MSG_ERROR(Test for socket failed.])
```
- チェック時に他にリンクしなければならないライブラリがあれば other-librariesのところに書く。例えば -lm や -lX11など。
AC_SEARCH_LIBS(function, search-libs, [action-if-found], [action-if-not-found])
- 例えばAC_SEARCH_LIBS(dlopen, dl dnl, [AC_DEFINE(HAVE_DLOPEN)])など
- 関数functionを空白で区切られた複数のライブラリsearch-libs から見つかるまで探す

∧ < = >

configure.in を編集 (5): ヘッダファイルのチェック

AC_CHECK_HEADER(header-file, [action-if-found], [action-if-not-found], [includes])
- ヘッダファイルheader-fileの存在をチェックする
- 例えば AC_CHECK_HEADER(errno.h, [AC_DEFINE(HAVE_ERRNO_H)])など
- 見つかればaction-if-foundが、見つからなければaction-if-not-foundが実行される
- 見つかったときに単に該当する変数を定義したい場合、 AC_CHECK_HEADERSを使うべし
AC_CHECK_HEADERS(header-files..., [action-if-found], [action-if-not-found], [includes])
- 空白で区切られた複数のヘッダファイルheader-filesをチェックする。
- action-if-found のところに break としておくと、先頭から見ていって一つでもヘッダが見つかればそこでループを抜ける。同等な定義を持つ複数のヘッダファイルのチェックに便利。
- 例えば AC_CHECK_HEADERS(string.h strings.h, break)など。
- 該当するヘッダファイルが見つかった場合は変数HAVE_ヘッダファイル名_Hが定義される。 (ex. HAVE_STDLIB_Hなど)
- ソースコード中の使用例 (config.hをインクルードすること)
```
#if HAVE_STRING_H
# include <string.h>
#else
# if HAVE_STRINGS_H
#  include <strings.h>
# else
#  include "my_string.h"
# endif
#endif
```

∧ < = >

configure.in を編集 (6): 関数のチェック

定番関数のチェック (alloca, chown, fork, vfork など)
- AC_FUNC_ALLOCA, AC_FUNC_CHOWN, AC_FUNC_FORKなど、関数fundをチェックするための AC_FUNC_funcというマクロがいくつか既定で用意されている
- この手のマクロを書いておくと、基本的には該当する関数があったり動いたりすれば HAVE_ALLOCAやHAVE_WORKING_FORK、 HAVE_WORKING_VFORKなどが定義される
- しかしそれぞれ細かく動作が違うので詳しくはマニュアルを
AC_CHECK_FUNC(function, [action-if-found], [action-if-not-found])
- 関数functionの存在をチェックする
- 例えばAC_CHECK_FUNC(uname, [AC_DEFINE(HAVE_UNAME)])
- 見つかればaction-if-foundが、見つからなければaction-if-not-foundが実行される
- 見つかったときに単に該当する変数を定義したい場合、 AC_CHECK_FUNCSを使うべし
AC_CHECK_FUNCS(functions..., [action-if-found], [action-if-not-found])
- 空白で区切られた複数の関数functionsをチェックする。
- action-if-found のところに break としておくと、先頭から見ていって一つでも関数が見つかればそこでループを抜ける。同等な定義を持つ複数の関数のチェックに便利。
- 例えばAC_CHECK_FUNCS(bzero memset, break)など。
- 該当するヘッダファイルが見つかった場合は変数HAVE_FUNCが定義される。
- ソースコード中の使用例 (config.hをインクルードすること)
```
#if !HAVE_BZERO && HAVE_MEMSET
#define bzero(buf, bytes)  ((void)memset(buf, 0, bytes))
#endif
```

∧ < = >

configure.in を編集 (7): その他のチェック

AC_TRY_COMPILE(includes, function-body, [action-if-found, [action-if-not-found]])
- 実際にfunction-bodyを含むコードをコンパイルできるかチェックする
- includes には function-bodyを実行するのに必要なすべての #include 文を書く
- 例えばプロトコル非依存なsocketアドレス情報を格納する構造体 struct addrinfo が定義されてるかチェックするには
```
AC_MSG_CHECKING(for addrinfo)
AC_CACHE_VAL(ac_cv_struct_addrinfo,
AC_TRY_COMPILE([
# include <sys/types.h>
# include <netdb.h>],
 [struct addrinfo s],
 ac_cv_struct_addrinfo=yes,
 ac_cv_struct_addrinfo=no))
AC_MSG_RESULT($ac_cv_struct_addrinfo)
if test $ac_cv_struct_addrinfo = yes; then
  AC_DEFINE(HAVE_STRUCT_ADDRINFO, [1], [Define to 1 if you have struct addrinfo])
fi
```
  上のコードがやってることは：
  1. addrinfo をチェックしてるメッセージを表示 (AC_MSG_CHECKING)
  2. AC_TRY_COMPILE のチェック結果をキャッシュするよう指示 (AC_CACHE_VAL)
  3. sys/types.h と netdb.h をインクルードして struct addrinfo s だけを含むコードがコンパイルできるかチェックし、できるなら ac_cv_struct_addrinfo に yes を、できないなら no を設定
  4. addrinfo のチェック結果を表示 (AC_MSG_RESULT)
  5. チェック結果が yes なら config.h (AC_CONFIG_HEADERで指定したヘッダファイル)でHAVE_STRUCT_ADDRINFO を定義する
独自マクロによる進んだ環境チェック
- M4マクロライブラリなどから必要な機能・関数・パッケージ・環境をチェックするマクロを取ってきて acinclude.m4 の中にコピペし、configure.in から呼び出すと便利
- 自分で AC_DEFUN マクロを使って新しいマクロを定義することも可能

∧ < = >

configure.in を編集 (8): ファイルの出力

configure に出力させるファイルの定義
- AC_CONFIG_FILES([files...])
  - Makefile など出力させたい設定ファイル名を書く
  - とりあえず src というディレクトリが増えたので以下のようにしましょう
    AC_CONFIG_FILES([Makefile src/Makefile])
- AC_CONFIG_HEADERS([files...])
  - config.h など出力させたいヘッダファイル名を書く
  - automake を使う場合は AM_CONFIG_HEADER([files...])
  - とりあえずAM_CONFIG_HEADER([config.h])とか
- 前のバージョンではAC_OUTPUT(Makefile src/Makefile)のように書いていたが、最近のものはAC_CONFIG_XXX([])で定義しておくと最後に AC_OUTPUT を呼んだ時に定義されたものが全て出力されるような
Makefile.am に値を渡す
- 基本的には configure 中の各マクロによって定義された変数 VARNAMEは Makefile.am 中で@VARNAME@で参照できる
- AC_SUBST(variable, [value])
  - 自分で定義した変数を Makefile.am 中で使いたい場合はコレ
  - AC_SUBST しておくと、configure 時に AC_CONFIG_FILESで指定したファイル(Makefileなど) を出力するときにファイル中の@variable@の部分が変数variableの値で置換される
config.h に値を渡す
- 基本的には configure 中のマクロによって定義された変数 VARNAMEは config.h 中でもdefineされる
- AC_DEFINE(variable, value, [description])
- AC_DEFINE(variable)
  - なにか明示的に config.h 中で define させたい場合はコレ
  - AC_DEFINE しておくと、configure 時に AC_CONFIG_HEADERSで指定したファイル(config.hなど) を出力するときに変数variableがdefineされる

∧ < = >

Makefile.am を作る (1) : 基本

Makefile.am は基本的に各ディレクトリに必要
まずそのディレクトリでビルドされるターゲットのファイル名を指定
- プログラムならbin_PROGRAMS = ターゲット
- ライブラリならlib_LIBRARIES = ターゲット (e.x. lib_LIBRARIES = libtest.a)
- libtool を使う場合 lib_LTLIBRARIES = ターゲット (e.x. lib_LTLIBRARIES = libtest.la)
  - 注: 共有ファイルを作りたい場合 libtool が必要。libtool を使うには configure.in に AC_PROG_LIBTOOL を足して libtoolize --force --copy; aclocal; automake -a -c; autoconf しておくこと。libtool はライブラリに関する機種依存部を隠蔽してくれるので、利用することを推奨
- マニュアルならman_MANS = ターゲット.1
- ターゲットは複数指定可
次にそのターゲットをビルドするのに必要なファイルを記述
- ソースファイルはターゲット_SOURCESで指定
- ライブラリはターゲット_LDADDで指定 (e.x. hoge_LDADD = libhoge.a あるいは libtool により構成されるライブラリをリンクする場合hoge_LDADD = libhoge.la)
- オブジェクトはターゲット_LIBADDで指定
- その他、_DEPENDENCIES, _LDFLAGS などを指定できる
- 条件によって必要となるファイルを指定するは先頭に EXTRA_ をつける
  - 例えば linux 上でビルドするときのみ必要になる hoge-linux.c というソースファイルを指定する場合、
    EXTRA_ターゲット_SOURCES = hoge-linux.c
- ターゲット名が "." などを含む場合 "_" に変換 (e.x. libtest.a → libnet_a_XXXX)
一般的なケースでは _SOURCES だけが必要。 _LDADD や _LIBADD はそのターゲットをビルドするのに特に必要なものを指定するのに使う (全体的に必要なライブラリは configure などで LIBS や LDADD に設定しておくのが普通)

∧ < = >

Makefile.am を作る (2) : 例

トップレベルの Makefile.am 例
- 今回の場合 SUBDIRS = src とだけ書けばOK
- サブディレクトリが増えたら空白で区切って後ろに追加する。
プログラムprogのための Makefile.am例
- PROGRAMS や MANS の "_" の前の単語 (bin や man) は、基本的にはmake installとするとインストールされるディレクトリ名。 (man の場合は拡張子.nを見てmann 以下にインストールされる)
- インストールされたくないものの場合は noinst_PROGRAMS のようにする。
- @VARNAME@ のようにして configure で定義された変数を使える。
- なお、configure 中でマクロでチェックしたライブラリは既に変数LIBSに足されており、これは make がリンク時に勝手に読んでくれるので明示的に指定する必要はない。その他、CFLAGS, CPPFLAGS, LDFLAGS などの変数についても特にすることはなし

ライブラリlibhogeのための Makefile.am例

  lib_LIBRARIES = libhoge.a
  libhoge_a_SOURCES = hoge.c parse.c

∧ < = >

Makefile.am を作る (3) : 応用例

同じソースから複数名のプログラムをコンパイルする場合

Automake 1.5 の場合、深く考えずに以下のようにすればOK
- etags.c から etags と ctags を違うコンパイルオプションで生成
```
bin_PROGRAMS = etags ctags
etags_SOURCES = etags.c
etags_CFLAGS = -DETAGS
ctags_SOURCES = etags.c
ctags_CFLAGS = -DCTAGS
```

ちなみに Automake 1.4 の場合こうしないといけなかった

bin_PROGRAMS = etags ctags
etags_SOURCES = etags.c
ctags_SOURCES = 
ctags_LDADD = ctags.o

etags.o: etags.c
	$(CC) $(CFLAGS) -DETAGS

ctags.o: etags.c
 	$(CC) $(CFLAGS) -DCTAGS

∧ < = >

仕上げと実例

仕上げ
- aclocal
  - ディレクトリ以下にある*.m4とconfigure.in を探索し、configure用のm4マクロファイル aclocal.m4を生成。探索したいサブディレクトリを足すには -I dirname のように -I オプションを指定する
- autoheader
  - configure.inから configure用のテンプレートヘッダファイル config.h.inを生成
- automake -a -c
  - Makefile.amからMakefile.inを生成
  - ちなみに -a (--add-missing)オプションは足りないファイルを勝手に生成してくれるオプション。-c (--copy)は、足りないファイルを生成する時にリンクではなくコピーしてくれる。
  - さらにちなみにちょっと前の automake では、 (-a オプションを付けていても) 用意しておかないといけないファイルがいくつかあった。昔の automake を使うときには最低 NEWS README AUTHOR ChangeLog の4つのファイルを (空でいいので)作っておく必要がある。
- autoconf
  - configure.inとaclocal.m4などから configureスクリプトを生成
gtk2.0 を使った小さいプログラムの例
- 普通に configure を使って書かれているオープンソースのその辺を読む方がいいかも
- ツリー gtktest
- アーカイブtar.gz

新しめの Autotools (Autoconf&Automake) を使ってみよう

Table of Contents

変更履歴

Autotools とは

基本ステップ

基本ステップ復習

ソースファイルを書く

autoscan する

configure.in を編集 (1)

configure.in を編集 (2): 先頭定型文

configure.in を編集 (3):プログラムのチェック

configure.in を編集 (4): ライブラリのチェック

configure.in を編集 (5): ヘッダファイルのチェック

configure.in を編集 (6): 関数のチェック

configure.in を編集 (7): その他のチェック

configure.in を編集 (8): ファイルの出力

Makefile.am を作る (1) : 基本

Makefile.am を作る (2) : 例

Makefile.am を作る (3) : 応用例

仕上げと実例