• HackingWithGnu
• GnuAutoconfPartTwo

第七回 GNU Autoconf (2)

configure.ac に必須なマクロ

では、 Autoconf のスクリプト・ファイルである configure.ac の書き方について、もっと具体的に踏み込んでいくことにしよう。 まず絶対不可欠なマクロを説明する。

必ず最初にないと駄目なのが、AC_INIT である。 このマクロはパッケージの名称、バージョン番号、バグの報告先を指定し、コマンド・ラインの引数の解析や configure 全体の初期化を行う。 ここで指定したパッケージ名等は、ユーザへの情報として利用される他、配布パッケージの作成や出力する変数の値に使われるので、大変重要なものである。

AC_INIT は次のように使用する。

AC_INIT([hello], [1.0], [bugs@example.com])

ここで、最初の引数 hello はパッケージの名称であり、1.0 がバージョン番号、bugs@example.comがバグの宛先（メールアドレス）だ。 普通ソフトウェアの名前は変わらないが、バージョンは度々変更されるものだ。 しかし、Autoconf を使うと、このおかげで、バージョンを一括して管理できる。 このマクロは自動的に PACKAGE_NAME と PACKAGE_VERSION という変数を定義し、 AC_SUBST を実行する。 AC_SUBST は変数を置換するためのマクロだ。 だから、Makefile.in に

PACKAGE_NAME = @PACKAGE_NAME@

とあると、勝手にその名前が分かるようになるわけだ。もっとも本当に役に立つのはこういうときだ。

   1 /* Print out the version information on the screen.  */
   2 void
   3 print_version (void)
   4 {
   5   printf ("%s %s\n", PACKAGE_NAME, PACKAGE_VERSION);
   6 }

次に、通常最後から二番目に表記するのだが、AC_CONFIG_FILES を使用しなければならない。 この引数は、ほとんどの場合、Makefile の羅列である。例えば、

AC_CONFIG_FILES([Makefile lib/Makefile src/Makefile doc/Makefile])

これによって、Makefile.in から Makefile が生成され、 lib/Makefile.in から lib/Makefile が生成され、以下同様、となる。 もちろん、ここには Makefile 以外のものを書いても良いが、 make 中に生成させることが多いように感じる。 それは場合によるとしか言いようがない。 個人的には Makefile 以外のものを AC_CONFIG_FILES させるのは極力避けることにしている。

本当は AC_CONFIG_FILES はもっといろんなことができる。 例えば、foo を AC_CONFIG_FILES によって指定すると、デフォルトでは、foo.in がテンプレートとして用いられる。 このとき、テンプレートとして、foo.in 以外のファイルを使わせることもできる。 しかし、それはこの連載の守備範囲を越えてしまう話題なので、あえて考えないことにしたい。 このポリシーは以後も同様で、実際にはもっとたくさんのことができる場合がある。 詳しくは自分でマニュアルを見て欲しい。

さて、一番最後に AC_OUTPUT を指定しなければならない。 このマクロにより、変数の置換など、あらゆる出力処理が実行に移されるのだ。 次のように、引数は全く指定する必要がない。

AC_OUTPUT

Automake を使うので

一応、Autoconf に不可欠なのは上の三つだけとなっているが、我々は Automake を使うので、もう一つ必要なものがある。 それは AM_INIT_AUTOMAKE だ。 このマクロは Autoconf ではなく、Automake が提供しているが、同じように使用できる。

ちょっと話がそれるが、Automake のマクロは全て、AM_ で始まる。 Autoconf なら、AC_ である。 なぜかと言うと、名前が衝突しないことを保証するためだ。 M4 には名前空間なんてものは存在しないので、こういう接頭辞を付けるしか、防ぐ方法がない。 だから、あなたが自分でマクロを作るときも必ず固有の接頭辞を付けて欲しい。

AM_INIT_AUTOMAKE は次のようにして使う。 AC_INIT の直後に呼ぶ必要があることに注意したい。

AC_INIT([hello], [1.0], [bugs@example.com])
AM_INIT_AUTOMAKE

本当は引数の指定も可能なのだが、実際に指定する必要性は滅多に生じないだろう。 以前の Automake では、パッケージ名をこのマクロで指定していたが、 この機能は Autoconf に移されたため、Automake が面倒を見る必要はなくなったのだ。 古いバージョンを使ってきた人は注意していただきたい。

実際には、AM_INIT_AUTOMAKE はたくさんのことをやってくれる。 例えば、AC_PROG_MAKE_SET を勝手に呼び出してくれる。 このマクロは、もし make が環境変数 MAKE に自動的にプログラム名を設定してくれない場合に、 Makefile にあらかじめ変数 MAKE を設定するために使われる。 この動作は常に必要とされるものなので、勝手にやってくれると楽でいい。 ちなみに、Automake は必要な Makefile の変数を勝手に用意してくれるので、この「MAKE を設定しないかもしれない make」の問題は全く意識しなくて良くなることにも注意して欲しい。

コンパイルの環境を整える

コンパイルに必要な環境を整える方法について考えよう。 Autoconf の利点の一つはその柔軟性であり、ユーザがどんなコンパイラを使うか設定できなければならない。 そのため、盲目的に cc を呼び出したりするのは良くない。 C コンパイラを見付けるにはこうする。

AC_PROG_CC

これだけである。 同様に、AWK には AC_PROG_AWK、Fortran 77 コンパイラには AC_PROG_F77 などが用意されている。 これらを列挙しても意味がないので、マニュアルを参照して欲しい。

だが残念ながら、ときにはそういう特別なマクロが用意されていないプログラムを見付ける必要がある。 例えば、ld を直接呼び出したいとする。 このとき、次のように、AC_CHECK_PROG を使う。

AC_CHECK_PROG(LD, ld)

このマクロは ld というプログラムを 環境変数 PATH の中から探し出す。 見付かれば、LD に ld を設定する。 もし絶対 ld がないといけない場合、次のようにしてエラーを起こすべきだ。

AC_CHECK_PROG(LD, ld)
if test "x$LD" = x; then
  AC_MSG_ERROR([cannot find ld])
fi

何だこれ？と思った人がいるかもしれないが、 configure はシェル・スクリプトなので、このようにシェル・スクリプトをそのまま書くことができるのだ。 もしシェル・スクリプトが知らないなら、そっちから勉強した方が良いだろう。 UNIX 系の開発者たる者、シェル・スクリプトも書けないでは済まされないのである。 これによって、LD が空だった場合、マクロ AC_MSG_ERROR が呼び出されることになる。 AC_MSG_ERROR は引数を画面に出して、異常終了するためのマクロだ。

しかし、ここでちょっと落とし穴がある。 これではクロス・コンパイルできないのだ。 普通クロス・コンパイルに使われるツールには、そのターゲットとなるプラットホームを示す接頭辞が付けられる。 例えば、i386-gnu に対して i386-gnu-ld のように。 だが、このやり方だと、i386-gnu-ld ではなく ld が見付けられてしまう。 ユーザに、./configure LD=i386-gnu-ld を実行させるのも手だが、ちょっと親切心に欠ける気がする。

そこでこうしよう。まずターゲットを決定するために、

AC_CANONICAL_HOST

を実行しておき、

AC_CHECK_TOOL(LD, ld)

とするのだ。 PROG が TOOL に換わっただけかよ、と思うかもしれない。 しかし、このマクロは先にそのターゲットの接頭辞を付けたファイル名から探す。 だから、クロス・コンパイラに対しても期待通りに振る舞う。

じゃあ、なぜ AC_CHECK_TOOL だけでは駄目なのか？ それは、全てのプログラムをクロス用にコンパイルするとは限らないからだ。 もしかすると、あなたのソフトウェアには、make 中に一時的に使用するプログラムを含んでいるかもしれない。 その場合、最初にそのプログラムをネイティヴ用にコンパイルしてから、それを使って、その後の make を進めることになる。 このように、ネイティヴとクロスを使い分けねばならないこともあるのだ。

少し話がややこしくなってきた。 よく分からなかった人は、「クロス・コンパイルってのは結構大変なんだな」とだけ分かってもらえればいい。

変数を置換する

すでに出てきたが、AC_SUBST というマクロがある。 これは変数を置換するために使われる。 実は、AC_PROG_CC のようなマクロは自動的に CC を置換してくれたりするのだが、自分で勝手に変数を作った場合にはそうはいかない。 例えば、--enable-debug が指定されると、 DEBUG = -g を加えるようにしたいとする (これはあんまり良くない例だ)。 すると、

AC_ARG_ENABLE([debug],
  AS_HELP_STRING([--enable-debug], [turn on the debugging feature]))
if test "x$enable_debug" = xyes; then
  DEBUG=-g
else
  DEBUG=
fi
AC_SUBST(DEBUG)

と書ける。 AC_ARG_ENABLE はまだ説明してないが、 --enable-foo を加えるためのマクロで、ここではあまり気にしないで欲しい。 もし --enable-debug が指定されると、 enable_debug に値 yes が代入される。 その場合、DEBUG は -g になり、指定されなければ空になる。これを最後に AC_SUBST する。

ソース・ディレクトリの指定

絶対なくてはならないというわけではないが、常に指定する習慣を身に着けた方が良いマクロに AC_CONFIG_SRCDIR がある。 このマクロは

AC_CONFIG_SRCDIR([hello.c])

のように、ソース・ファイルを引数に取るが、それ自体は何もしない。 では一体何の役に立つのか？

Autoconf の特徴の一つは、ソース・ディレクトリとビルド・ディレクトリを区別できることだ。 ソース・ディレクトリとは、あなたのパッケージのソースコードが存在するディレクトリのことで、 ビルド・ディレクトリとはパッケージの構築に使用する場所、つまり、コンパイルしたバイナリが置かれるディレクトリなのだ。 この機能は極めて有用で、ソース・ディレクトリがオブジェクト・ファイルでぐちゃぐちゃになるのを防いだり、 あるいは、クロス開発でさまざまなアーキテクチャ向けのバイナリを別個のディレクトリに配置することが可能となる。

例えば、筆者がコンパイルを行うとき、次のようにして実行することが多い。

$ mkdir objs
$ cd objs
$ ../configure
$ make

こうすると、万が一、make distclean などが思うように動かない場面でも、

$ cd ..
$ rm -rf objs

とするだけで、元の状態に簡易に復帰できるからだ。

しかし、このように別の場所で構築を行おうとすると、configure は何らかの手段でソースの位置を検出できないといけない。 ほとんどの場面ではうまく行くが、自動検出には限界がある。 ときには人間が configure --srcdir=dir と、--srcdir オプションを指定してあげないといけないこともある。

このような自動検出や手動検出において、間違いが発生する危険性については言うまでもない。 だから、AC_CONFIG_SRCDIR が役に立つのだ。 このマクロでパッケージに特異的な名称のファイルを指定しておけば、 configure は本当に正しい場所をソース・ディレクトリだと考えているのか確認してくれるのだ。

まとめ

今回は Autoconf で頻繁に使われるマクロをいくつか取り挙げた。 これでようやく 以前挙げた例 の configure.ac が分かるようになったはずだ。 次回はさらに、よく使われるマクロを中心に説明を続けたい。 それが終われば、より実際的な例を見て行くことになるだろう。 いつもの通り、質問、意見、批判などは okuji at enbug dot org まで送って欲しい

次の回 / 前の回 / はっきんぐ・うぃず・ぐにゅー に戻る。

Copyright © 1999,2000,2007 Yoshinori K. Okuji

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.