[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

5. `configure.ac'のスキャン

Automakeは,パッケージに関する特定の情報を決定するために,パッケージの `configure.ac'をスキャンします.必要なautoconfマクロもあれ ば,`configure.ac'で定義する必要がある変数もあります.Automakeは, 出力物を調整するためにも,`configure.ac'からの情報を使用します.

Automakeは,管理をより容易にするためのAutoconfマクロも提供しています. これらのマクロは,aclocalプログラムを使用して自動的に `aclocal.m4'に書き込むことが可能です.


5.1 コンフィグレーションの必要条件

Automakeが本当に必要としていることは一つで,`configure.ac'でマク ロAM_INIT_AUTOMAKEを呼び出すことです.このマクロは,適切な Automakeの処理に必要なことをいくつか行ないます(see section Automakeが提供するAutoconfマクロ).

Automakeは必要としますが,AM_INIT_AUTOMAKEで実行されないマクロ には,以下のものがあります.

AC_CONFIG_FILES
AC_OUTPUT

Automakeは,作成するファイルを決定するためにこれらを使用します (see (autoconf)Output section `Creating Output Files' in The Autoconf Manual).同じ名前のファイルが`.am'拡張子が後置されている状態で存 在している場合,リストアップされているファイルは,Automakeが `Makefile'を生成するものと考慮します.通常, AC_CONFIG_FILES([foo/Makefile])で,`foo/Makefile.am'が存在 する場合は,Automakeが`foo/Makefile.in' を生成します.

AC_CONFIG_FILES([Makefile:top.in:Makefile.in:bot.in])のように, 複数の入力ファイルでAC_CONFIG_FILESを使用しているとき,Automake は,存在する`.am'ファイルに対して,最初の`.in'入力ファイルを 生成します.そのようなファイルが存在しない場合,出力ファイルはAutomake が生成したものと考えません.

AC_CONFIG_FILESで生成されたファイルは,make distcleanで 削除されます.


5.2 その他のAutomakeが理解すること

Automakeは実行されるたびに,`configure.ac'を追跡するために Autoconfを呼び出します.この方法で,特定のマクロの使用を認識し,生成さ れる`Makefile.in'を適切に調整します.現在認識されるマクロとそれら の効果は,以下のようになっています.

AC_CONFIG_HEADERS

Automakeはこれらのヘッダをリビルドするルールを生成します.古いバージョ ンのAutomakeはAM_CONFIG_HEADERの使用を要求していました (see section Automakeが提供するAutoconfマクロ).これは今日では既に事実ではありません.

AC_CONFIG_LINKS

`configure'が生成したリンクをAutomakeはmake distcleanで削 除し,make distの部分で生成される指名されたソースファイルを配布 するためのルールを生成します.

AC_CONFIG_AUX_DIR

Automakeは,`install-sh'のような様々なヘルパースクリプトを,この マクロの呼び出しで指定されたディレクトリで探します.

(スクリプトの完全なリストは以下のとおりです.`config.guess', `config.sub', `depcomp', `elisp-comp', `compile',`install-sh', `ltmain.sh', `mdate-sh', `missing',`mkinstalldirs', `py-compile', `texinfo.tex',そして`ylwrap')すべてのスクリプトが常に探され るわけではありません.`Makefile.in'の要求で生成された場合だけ探さ れるスクリプトもあります.

AC_CONFIG_AUX_DIRが与えられていない場合,スクリプトは `standard'な場所で探されます.`mdate-sh',`texinfo.tex', そして`ylwrap'の標準的な場所は,現在の`Makefile.am'に対応す るソースディレクトリです.それ以外のものの標準的な場所は,最初は `.',`..',または`../..'(トップソースディレクトリに関連) で,それは経る羽ースクリプトの一つを提供しています.See (autoconf)Input section `Finding `configure' Input' in The Autoconf Manual.

AC_CONFIG_AUX_DIRで要求されるファイルは,このディレクトリに `Makefile.am'が無い場合でも自動的に配布されます.

AC_CANONICAL_HOST

Automakeは,`config.guess'と`config.sub'が確実に存在するよう にします.また,`Makefile'変数の`host_alias'と `host_triplet'も導入します.(autoconf)Canonicalizing section `Getting the Canonical System Type' in The Autoconf Manualを参照してくださ い.

AC_CANONICAL_SYSTEM

これはAC_CANONICAL_HOSTに似ていますが,`Makefile'変数の `build_alias'と`target_alias'も定義します. See (autoconf)Canonicalizing section `Getting the Canonical System Type' in The Autoconf Manual.

AC_LIBSOURCE
AC_LIBSOURCES
AC_LIBOBJ

Automakeは,AC_LIBSOURCEAC_LIBSOURCESでリストアップさ れているすべてのファイルを自動的に配布します.

AC_LIBOBJSマクロがAC_LIBSOURCEを呼び出すことに注意してく ださい.そのため,AutoconfマクロがAC_LIBOBJ([file])を呼び出すと 説明されている場合,`file.c'はAutomakeで自動的に配布されます.こ れには,AC_FUNC_ALLOCAAC_FUNC_MEMCMPAC_REPLACE_FUNCS等の多くのマクロが含まれます.

ところで,直接LIBOBJSに代入することは,既にサポートされていませ ん.この目的では常にAC_LIBOBJを使用すべきです.See (autoconf)AC_LIBOBJ vs LIBOBJS section `AC_LIBOBJ vs. LIBOBJS' in The Autoconf Manual.

AC_PROG_RANLIB

これは,ライブラリをビルドするパッケージの場合に必要になります. See (autoconf)Particular Programs section `Particular Program Checks' in The Autoconf Manual.

AC_PROG_CXX

これは,C++ソースが含まれる場合に必要になります.See (autoconf)Particular Programs section `Particular Program Checks' in The Autoconf Manual.

AC_PROG_F77

これは,Fortran77ソースが含まれる場合に必要になります.このマクロは Autoconfのバージョン2.13以降で配布されます.See (autoconf)Particular Programs section `Particular Program Checks' in The Autoconf Manual.

AC_F77_LIBRARY_LDFLAGS

これはFortran77を含む言語が混在しているプログラムと共有ライブラリに対 して必要になります(see section CとC++と,Fortran 77の混在). See section Autoconf macros supplied with Automake.

AC_PROG_FC

Fortran 90/95ソースが含まれる場合に必要になります.このマクロは Autoconfのバージョン2.58以降で配布されます.See (autoconf)Particular Programs section `Particular Program Checks' in The Autoconf Manual.

AC_PROG_LIBTOOL

Automakeはlibtoolに対する処理を開始します(see (libtool)Top section `Introduction' in The Libtool Manual).

AC_PROG_YACC

Yaccソースファイルがある場合,このマクロを使用するか, `configure.ac'で変数`YACC'を定義する必要があります.前者が好 まれます(see (autoconf)Particular Programs section `Particular Program Checks' in The Autoconf Manual).

AC_PROG_LEX

Lexソースファイルがある場合,このマクロを使用する必要があります. See (autoconf)Particular Programs section `Particular Program Checks' in The Autoconf Manual.

AC_SUBST

最初の引数は,それぞれの生成される`Makefile.in'で,変数として自動 的に定義されます.See (autoconf)Setting Output Variables section `Setting Output Variables' in The Autoconf Manual.

Autoconfマニュアルで,マクロがvarに対してAC_SUBSTを呼び出 すとか,出力変数varを定義するといった説明がある場合,varは それぞれのAutomakeが生成する`Makefile.in'で定義されます.例えば, AC_PATH_XTRAX_CFLAGSX_LIBSを定義するので, AC_PATH_XTRAが呼び出されている場合,`Makefile.am'でこれら 変数と使用することが可能です.

AM_C_PROTOTYPES

これは,de-ANSI-ficationを自動的に使用するときに必要です.自動的なde-ANSI-ficationを 参照してください.

AM_GNU_GETTEXT

このマクロはGNU gettextを使うパッケージに対して必要になります (see section Gettext).それはgettextとともに配布されます.Automakeがこのマ クロを見つけた場合,このマクロはパッケージがgettextの必要条件のいくつ かを確実に満たすようにします.

AM_MAINTAINER_MODE

このマクロはconfigureに`--enable-maintainer-mode'オプショ ンを加えます.これが使用されている場合,automakeは生成された `Makefile.in'内の`maintainer-only'ルールをデフォルトで停止し ます.このマクロは`MAINTAINER_MODE'条件を定義し,自分の `Makefile.am'で使用することが可能です.

m4_include

`configure.ac'でインクルードされるこのマクロを使用しているファイ ルはAutomakeで検索され,自動的に配布されます.それらは`Makefile' のルールで依存性として表現されます.

m4_includeが`configure.ac'の著者によって使用されることは滅 多にありませんが,aclocalがパッケージローカルのファイルにあ るマクロを要求していることを検出したとき,`aclocal.m4'に現れるは ずです(システム全域のディレクトリにインストールされているマクロとは異 なります.aclocal.m4の自動生成を参照して下さい).


5.3 aclocal.m4の自動生成

Automakeには,パッケージで使用可能な多くのAutoconfマクロがあります (see section Automakeが提供するAutoconfマクロ).状況によってはAutomakeが実際に必要とするものもありま す.これらのマクロは`aclocal.m4'で定義する必要があります.さもな ければ,それらはautoconfでは見つからないでしょう.

aclocalプログラムは,`configure.ac'の内容に基づいて自動的 に`aclocal.m4'ファイルを生成します.これは,Automakeが提供するマ クロを入手する便利な方法を提供し,それらを探し回る必要がないようになっ ています.aclocalのメカニズムで,他のパッケージに対して独自のマ クロを提供することも可能です(see section 独自のaclocalマクロを書く).また,カスタ ムマクロの独自セットを管理するためにそれを使用することも可能です (see section ローカルなマクロの処理).

はじめに,aclocalはマクロ定義を探しながら見つかったすべての `.m4'ファイルをスキャンします(see section マクロ検索パス).それか ら`configure.ac'をスキャンします.最初のステップで見つかったマク ロの記述によって,マクロとマクロが要求するファイルを`aclocal.m4' に書き込みます.

マクロ定義を含むファイルを`aclocal.m4'に書くことは,通常こ のファイルのテキスト全体を,`#'と`dnl'コメントを含め,未使用 のマクロまで含めてコピーすることで実行されます.aclocalがコメン トを完全に無視するようにしたい場合は,コメントの最初に`##'を使用 して下さい.

aclocalが選択しているファイルがaclocal-I オプションで相対的なサーチパスで指定されているパッケージのサブディレク トリに存在するとき,aclocalはそのファイルがパッケージに属し ていると仮定し,`aclocal.m4'にコピーする代わりにm4_include を使用します.これで,パッケージはより小さくなり,依存性の追跡がより容 易になり,ファイルを自動的に配布物に含めるようになります.(例は, see section ローカルなマクロの処理.) システム全体で,または絶対パスで検索され見つかっ たマクロはコピーされます.そのため,外部パッケージとして考慮する必要が ある相対的なディレクトリがあるときは,-I reldirの代わりに -I `pwd`/reldirを使用して下さい.

`acinclude.m4'の内容も,このファイルが存在する場合は自動的に `aclocal.m4'に含められます.我々は,新しいパッケージでの `acinclude.m4'の使用に反対します(see section ローカルなマクロの処理).

`aclocal.m4'を調べている間,実際に利用されているマクロを追跡し, 記述されているが要望されていないすべてのマクロを`aclocal.m4'から 削除するため,aclocalautom4teを実行します(see (autoconf)Using autom4te section `Using Autom4te' in The Autoconf Manual). autom4teautoconfと同じPATHにあることを期待され ています.その場所は,AUTOM4TE環境変数を使用して優先させること が可能です.


5.4 aclocalのオプション

aclocalは,以下のオプションを受け入れます.

--acdir=dir

インストールされたディレクトリの代わりに,dirでマクロファイルを 探します.これは,通常デバッグで使用します.

--help

コマンドラインオプションの概要を出力し,終了します.

-I dir

`.m4'ファイルを探すディレクトリのリストに,dirディレクトリ を追加します.

--force

出力ファイルを常に上書きします.デフォルトは,必要なときだけ,すなわち その内容が変更されたときや,その依存元がより新しい場合,出力ファイルを 上書きします.

--output=file

`aclocal.m4'の代わりに,fileに出力を書き込みます.

--print-ac-dir

サードパーティーの`.m4'ファイルを見つけるためにaclocalが検 索するディレクトリの名前を出力します.このオプションが与えられていると き,標準的な処理は行われません.このオプションは,パッケージがマクロファ イルをインストールする場所を決定するために使用することが可能です.

--verbose

調査しているファイルの名前を出力します.

--version

Automakeのバージョンナンバーを出力し,終了します.


5.5 マクロ検索パス

デフォルトで,aclocalは`.m4'ファイルを以下のディレクト リで,この順番に探します.

acdir-APIVERSION

これは,automake自身が配布している`.m4'マクロを保持している場所で す.APIVERSIONは,使用しているautomakeのリリースに依存します. automake 1.6.xに対して,APIVERSION = 1.6になります.

acdir

このディレクトリは,サードパーティーの`.m4'ファイルが目的で, automake自身がビルドされるときにconfigureされます.これは `@datadir@/aclocal/'で,通常`${prefix}/share/aclocal/'に 展開されます.組み込みのacdirを知るために,--print-ac-dir オプションを使用してください.

例として,automake-1.6.2が--prefix=/usr/localを用いてconfigure されたと仮定します.そのとき検索パスは以下のようになります.

  1. `/usr/local/share/aclocal-1.6/'

  2. `/usr/local/share/aclocal/'

(see section aclocalのオプション)で説明したように,この検索パスの変更や拡張で 使用可能なオプションもあります.


5.5.1 マクロ検索パスを変更する: --acdir

検索パスを変更する最も明確なオプションは--acdir=dirで,デ フォルトのディレクトリを変更し,APIVERSIONディレクトリを取り消し ます.例えば,--acdir=/opt/private/を指定した場合,検索パスは以 下のようになります.

  1. `/opt/private/'

このオプション--acdirの目的は,automakeのテストスイートの内部で 使用することだけです.それはエンドユーザは通常不要です.


5.5.2 マクロ検索パスを変更する: -I dir

-Iオプション(see section aclocalのオプション)を使用して,あらゆる追加ディ レクトリを指定することで,これらの検索リストに前置します.この ため,aclocal -I /foo -I /barは結果として以下のような検索パスに なります.

  1. `/foo'

  2. `/bar'

  3. acdir-APIVERSION

  4. acdir


5.5.3 マクロ検索パスを変更する: `dirlist'

検索パスをカスタマイズするため,三番目のメカニズムがあります. `dirlist'ファイルがacdirに存在する場合,そのファイルが,一 行ごとに検索リストに追加するディレクトリリストを含んでいると仮定されま す.これらのディレクトリは,すべての他のディレクトリの後に検索 されます.

例えば,`acdir/dirlist'が以下の内容を含んでいると仮定します.

 
/test1
/test2

そして,aclocal-I /foo -I /barオプションで呼び出したと 仮定します.そのとき検索パスは以下のようになります.

  1. `/foo'

  2. `/bar'

  3. acdir-APIVERSION

  4. acdir

  5. `/test1'

  6. `/test2'

--acdir=dirオプションが使用されている場合, aclocalは`dirlist'ファイルをdirで検索します.上記 の--acdir=/opt/private/の例では,aclocalは `/opt/private/dirlist'を探します.しかし,繰り返しますが, --acdirオプションの目的は,automakeのテストスイートの内部で使用 されることだけです.通常,--acdirはエンドユーザには不要です.

以下のような状況で,`dirlist'は役に立ちます.automakeのバー ジョン1.6.2が,`$prefix=/usr'でシステムベンダーによってイ ンストールされていると仮定します.このためデフォルトの検索ディレクトリ は以下のようになります.

  1. `/usr/share/aclocal-1.6/'

  2. `/usr/share/aclocal/'

しかし,システムには多くのパッケージが,いつも通りに `$prefix=/usr/local'に手動でインストールされていると仮定します. この状況では,これらの"追加の"`.m4'ファイルは `/usr/local/share/aclocal'にあります.これらの"追加の" `.m4' ファイルを見つけるため,`/usr/bin/aclocal'を強制させる 方法は,常にaclocal -I /usr/local/share/aclocalを呼び出すことで す.これは不便です.`dirlist'を用いると,以下のファイルを作成する ことができます.

`/usr/share/aclocal/dirlist'

その内容は以下のようになっています.

`/usr/local/share/aclocal'

さて,システムに影響する"デフォルト"の検索パスは以下のようになります.

  1. `/usr/share/aclocal-1.6/'

  2. `/usr/share/aclocal/'

  3. `/usr/local/share/aclocal/'

-Iオプションは不要です.-Iは,ローカルなシステム依存のツー ルのインストールディレクトリを回避するのではなく,プロジェクト独自のも のが必要な(`my-source-dir/m4/')として予約可能です.

同様に,Automakeのローカルコピーをアカウント内にインストールし, aclocalでシステムの他の場所にインストールされているマクロを 探したい場合,`dirlist'は手頃なはずです.


5.6 Automakeが提供するAutoconfマクロ

Automakeは,`configure.ac'で使用可能ないくつかのAutoconfマクロと ともに出荷されています.そのうちの一つを使用するとき,aclocalで `aclocal.m4'に含められるでしょう.


5.6.1 パブリックマクロ

AM_CONFIG_HEADER

Automakeは,コンフィグヘッダを自動的に再生成するルールを生成します.こ の時代遅れのマクロは,現在はAC_CONFIG_HEADERSと同じです (see section その他のAutomakeが理解すること).

AM_ENABLE_MULTILIB

これは,"multilib"ライブラリをビルドするときに使用します.最初のオプ ション引数は,生成される`Makefile'の名前です.デフォルトは `Makefile'です.二番目のオプション引数は,ソースディレクトリのトッ プを見つけるために使用します.デフォルトは空の文字列です(内部を理解し ていない場合,通常はこれを使用しないほうが良いでしょう.) See section Multilibのサポート.

AM_C_PROTOTYPES

関数プロトタイプをコンパイラが理解するかどうかを調査します.その場合, `PROTOTYPES'を定義して,出力変数`U'と`ANSI2KNR'を空の文 字列に設定します.それ以外の場合,`U'を`_'に, `ANSI2KNR'を`./ansi2knr'にします.Automakeはこれらの値を自動 的なde-ANSI-ficationを実装するために使用します.

AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL

TIOCGWINSZを使用するときに`<sys/ioctl.h>'が必要な場合, GWINSZ_IN_SYS_IOCTLを定義します.それ以外の場合, TIOCGWINSZは`<termios.h>'で見つかるはずです.

AM_INIT_AUTOMAKE([OPTIONS])
AM_INIT_AUTOMAKE(PACKAGE, VERSION, [NO-DEFINE])

生成されたMakefileが適切な処理を行なうために必要な多くのマクロを実行し ます.

このマクロには二つの形式があり,最初のものが好まれます.この形式では, AM_INIT_AUTOMAKEは単一の引数で呼び出されます -- ツリー内のすべ ての`Makefile.am'に適用するAutomakeオプションのスペースで分離され ているリストです.それぞれのオプションがAUTOMAKE_OPTIONSでリス トアップされているかの様な効果があります.

反対されている二番目のAM_INIT_AUTOMAKEの形式は,二つの引数が必 要です.パッケージとバージョンナンバーです.この形式は,packageversionがAutoconfのAC_INITマクロ(それ自身も古い形式と新 しい形式があります)から得ることが可能なので時代遅れです.

`configure.ac'が以下の場合を考えます.

 
AC_INIT(src/foo.c)
AM_INIT_AUTOMAKE(mumble, 1.5)

以下のようにして新しいものにすることが可能です.

 
AC_INIT(mumble, 1.5)
AC_CONFIG_SRCDIR(src/foo.c)
AM_INIT_AUTOMAKE

`configure.ac'を以前のバージョンのAutomakeから更新している場合, 上記の例のように,単純にパッケージバージョンの引数を,直接 AM_INIT_AUTOMAKEからAC_INITへ移動することが常に正しいと は限りません.AC_INITの最初の引数はパッケージの名前(例えば `GNU Automake')ですが,AM_INIT_AUTOMAKEに渡すために使用し ているtarballの名前(例えば`automake')ではありません.Autoconfはパッ ケージ名からtarball名を導き出すことを試み,それはほとんどのパッケージ で動作しますが全てで動作するとは限りません.(うまく動作しない場合 -- Autoconfのバージョン2.52g以上からサポートされている -- tarball名を明 示的に提供する,AC_INITの四つの引数を用いる形式を使用することが 可能です).

デフォルトでこのマクロは`PACKAGE'と`VERSION'を AC_DEFINEします.以下のように`no-define'オプションを渡すこ とでこれを避けることが可能です.

 
AM_INIT_AUTOMAKE([gnits 1.5 no-define dist-bzip2])

または時代遅れの形式に空の三番目に引数を渡すことで避けることが可能です.

AM_PATH_LISPDIR

emacsプログラムを検索し,見つかった場合は,Emacsのsite-lispディ レクトリへのフルパスを出力変数lispdirに設定します.

このテストは(GNU EmacsやXEmacsのような)Emacs Lispをサポートしてい るバージョンのemacsが見つかることを想定しています.それ以外の emacsenでは,このテストはハングアップします(古いバージョンのMicroEmacs のように,対話モードでセットアップされているものは,終了するために `C-x C-c'が必要で,emacsユーザでなければなかなか気付かないでしょ う).しかし,ほとんどの状況で,テストを終了するために`C-c'を使用 することが可能でしょう.問題を避けるため,環境変数でEMACSを "no"に設定したり,(Emacs Lispをサポートしているemacsが確実に ある場合は)正しいパスを明示的に設定するためにconfigureで `--with-lispdir'を使用することが可能です.

AM_PROG_AS

プロジェクトにアセンブラコードがあるときは,このマクロを使用して下さい. これはアセンブラを選択し(デフォルトはCコンパイラ),CCASを設定し, そして,必要な場合はCCASFLAGSも設定します.

AM_PROG_CC_C_O

これはAC_PROG_CC_C_Oに似ていますが,それはautomakeが要求する形 式の結果を生成します.この機能が必要なときは,AC_PROG_CC_C_Oの 代わりにこれを使用して下さい.

AM_PROG_LEX

AC_PROG_LEXに似ていますが(see (autoconf)Particular Programs section `Particular Program Checks' in The Autoconf Manual),lex が無いシステムでmissingスクリプトを使用します.`HP-UX 10' はそのようなシステムの一つです.

AM_PROG_GCJ

このマクロは,gcjプログラムを見つけるか,そうでなければエラーを 発生します.それは`GCJ'と`GCJFLAGS'を設定します.gcj は,GNU Compiler CollectionのJavaフロントエンドです.

AM_SYS_POSIX_TERMIOS

POSIX termiosヘッダと関数がシステムで利用可能かどうか調査します.その 場合,シェル変数am_cv_sys_posix_termiosを`yes'に設定します. そうでない場合,その変数を`no'に設定します.

AM_WITH_DMALLOC

dmallocパッケー ジに対するサポートを追加します.ユーザが`--with-demalloc'を用いて configureする場合,WITH_DMALLOCを定義し,LIBSに `-ldmalloc'を加えます.

AM_WITH_REGEX

configureコマンドラインに`--with-regex'を追加します.指定 されている(デフォルトの)場合,`regex'の正規表現ライブラリが使用さ れ,`regex.o'が`LIBOBJS'に書き込まれ,そして, `WITH_REGEX'が定義されます.`--without-regex'が与えられる場 合,`rx'正規表現ライブラリが使用され,`rx.o'が`LIBOBJS' に書き込まれます.


5.6.2 プライベートマクロ

以下のマクロは,直接呼び出すべきではないプライベートマクロです.それら は適切なときに他のパブリックマクロから呼び出されます.将来のバージョン で変更される可能性があるので,それらを呼び出さないでください.それらは 実装の詳細を考察するものと考えてください.または,何も考えないほうが良 いかもしれません.このセクションは読み飛ばしてください!

_AM_DEPENDENCIES
AM_SET_DEPDIR
AM_DEP_TRACK
AM_OUTPUT_DEPENDENCY_COMMANDS

これらのマクロはAutomakeの自動的な依存性の追跡手法を実装するために使用 されます.それらは,要求されたときAutomakeから自動的に呼び出され,手動 で呼び出す必然性はありません.

AM_MAKE_INCLUDE

このマクロは,ユーザのmakeinclude文を処理する方法を知 るために使用されます.それらは,必要なとき自動的に呼び出されます.手動 で呼び出す必然性はありません.

AM_PROG_INSTALL_STRIP

これは,インストール時にプログラムをstripするために使用可能な installのバージョンを知るために使用されます.このマクロは要求さ れるとき自動的にインクルードされます.

AM_SANITY_CHECK

これは,ビルドディレクトリに作成されるファイルがソースディレクトリのファ イルより確実に新しいことを調査します.時計の設定が正しくないシステムで 失敗するはずです.このマクロはAM_INIT_AUTOMAKEから自動的に実行 されます.


5.7 独自のaclocalマクロを書く

aclocalプログラムには,マクロ組み込みの知識が全く無いので, 独自のマクロでそれを拡張することは容易です.

これは,他のプログラムで使用する独自のAutoconfマクロを,供給したいライ ブラリに対して使用することが可能です.例えばgettextライブラリは, gettextを使用しているあらゆるパッケージで使用されるように, AM_GNU_GETTEXTマクロを提供しています.ライブラリがインストール されるとき,aclocalで見つかるように,このマクロをインストールし ます.

マクロファイルの名前は`.m4'で終わらせすべきです.そのようなファイ ルは`$(datadir)/aclocal'にインストールされます.簡単に書くと以下 のようになります.

 
aclocaldir = $(datadir)/aclocal
aclocal_DATA = mymacro.m4 myothermacro.m4

マクロのファイルは,AC_DEFUN (see (autoconf)Macro Definitions section `Macro Definitions' in The Autoconf Manual)で適切に引用符で囲むべきです. aclocalプログラムはAC_REQUIRE (see (autoconf)Prerequisite Macros section `Prerequisite Macros' in The Autoconf Manual)も理解するので,個別のファ イルのそれぞれのマクロに書き込んでも大丈夫です.それぞれのファイルには マクロ定義以外の副作用が無いようにすべきです.特に,AC_PREREQの 呼び出しは,マクロ定義内部にすべきでファイルの最初に書くべきではありま せん.

Automake 1.8から,aclocalは,引用符で囲まれていない AC_DEFUNの呼び出しすべてに警告を発するようになっています.我々 はこれで,人々がうんざりすることを自覚していて,それは aclocalはこれまであまり厳密ではなく,多くのサードパーティー のマクロは引用符で囲まれていないためです.そして我々は,この一時的な不 便さを謝罪しなければなりません.我々が厳密にする必要がある理由は,将来 のaclocal (see section aclocalの将来)の実装で,一時的にこれ らすべてのサードパーティーの`.m4'ファイルを,可能性としては複数回, 不要なものであっても,インクルードする必要があるためです.そうすること で,多少なりとも現在の実装では多くの問題があるのですが,より厳密な形式 をマクロの著者に要求することになります.希望としては,既存のマクロを ちょっと修正して欲しいと思っています.例えば以下のようにします.

 
# bad style
AC_PREREQ(2.57)
AC_DEFUN(AX_FOOBAR,
[AC_REQUIRE([AX_SOMETHING])dnl
AX_FOO
AX_BAR
])

以下のように書き換えるべきです.

 
AC_DEFUN([AX_FOOBAR],
[AC_PREREQ(2.57)dnl
AC_REQUIRE([AX_SOMETHING])dnl
AX_FOO
AX_BAR
])

AC_PREREQの呼出をマクロ内にラップすることで,Autoconf 2.57は, AX_FOOBARを実際に使用しない場合は要求しなくなります.最も重要な ことは,AC_DEFUNの最初の引数を引用符で囲むことで,マクロを再定 義したり,二回インクルードすることが可能になります(そうしなければ,こ の最初の引数は二番目の定義の間展開されたままです).

このようなaclocalの診断が示された場合,マクロ実装の管理者で はない場合,マクロの管理者に連絡したいかもしれません.マクロの最新バー ジョンと,そのような報告が以前になされていないことを確認ししてください. 人は,メールの洪水がないときには,すぐにでも仕事をするものです.

aclocalを一般的に使用するもう一つの状況は,パッケージローカ ルのマクロを管理するときです.ローカルなマクロの処理を参照して下さい.


5.8 ローカルなマクロの処理

Autoconfで提案される機能テストは,すべてのニーズをカバーしていません. 独自のマクロやサードパーティーのマクロで既存のテストを補足する必要があ ることもよくあります.

パッケージのカスタムマクロを体系付ける方法は二つあります.

利用可能な最初の方法は(歴史的な手法で)すべてのマクロを `acinclude.m4'にリストアップすることです.このファイルは aclocalの実行時に`aclocal.m4'に含められ,そのマクロはそ れ以降autoconfから見えるようになります.しかし,たくさんのマ クロを含んでいる場合,ちょっとした管理が難しくなり,パッケージ間でマク ロを共有することが不可能になります.

利用可能な二番めの方法は,こちらが推奨されていますが,それぞれのマクロ を単独ファイルに書き,一つのディレクトリにこれらすべてのファイルをまと めておくことです.このディレクトリは通常`m4/'と呼ばれています.こ のため,`aclocal.m4'をビルドする際,aclocalに`m4/' をスキャンするように指示するべきです.コマンドラインからは, aclocal -I m4とします.または,最上位のの`Makefile.am'の定 義を以下のように更新すべきです.

 
 ACLOCAL_AMFLAGS = -I m4

ACLOCAL_AMFLAGSは,`aclocal.m4'がmakeでリビルドされ るとき,aclocalに渡すオプションを含んでいます.この行は,適 切なオプションでaclocalを実行するため,autoreconf (see (autoconf)autoreconf Invocation section `Using autoreconf to Update `configure' Scripts' in The Autoconf Manual)や,Gettextの マクロがインストールされている場所を示すためautopoint (see (gettext)autopoint Invocation section `Invoking the autopoint Program' in GNU gettext tools)とgettextize (see (gettext)gettextize Invocation section `Invoking the gettextize Program' in GNU gettext tools)でも使用されます.そのため,リビ ルドのルールであまり注意していなくても,ACLOCAL_AMFLAGSを定義す べきです.

aclocal -I m4が実行されるとき,要求されているマクロが定義されて いる`m4/'のあらゆるファイルをm4_includeし, aclocal.m4をビルドします.ローカルに見つからないマクロは, マクロ検索パスで説明されているシステム全体のディレクトリで検 索されます.

カスタムマクロは`configure.ac'と同じ理由で配布すべきです.パッケー ジを動作させたい人は,そのすべてのファイルを持っているようにすべきです. 実際これは,すべてのm4_includeされるファイルが配布されるので, 自動的に配布されます.

しかし,パッケージで使用しているサードパーティーのマクロの配布には一致 している見解はありません.多くのライブラリは,独自のマクロをシステム全 体のaclocalディレクトリ(see section 独自のaclocalマクロを書く)にインストー ルします.例えば,Guileはコンパイラの設定とGuileを使用する際に適切なリ ンカフラグ定義するために使用することが可能な,マクロGUILE_FLAGS を含んでいる`guile.m4'と呼ばれるファイルを配布しています. `configure.ac'でGUILE_FLAGSを使用することで, aclocalは`guile.m4'を`aclocal.m4'にコピーしますが, `guile.m4'はプロジェクトの一部ではないので,それは配布していませ ん.技術的には,`aclocal.m4'をリビルドする必要があるユーザはGuile を最初にインストールする必要があることを意味します.Guileがパッケージ のビルドで必要な場合,これはおそらく問題無いでしょう.しかし,Guileは 単なる追加機能だったり,パッケージをGuileがインストール不可能なマシン で実行する可能性がある場合,この必要条件は開発の邪魔になります.簡単な 解決方法は,そのようなサードパーティーのマクロを,それらも配布されるよ うに,ローカルな`m4/'ディレクトリにコピーすることです.


5.9 aclocalの将来

aclocalの消滅が予想されています.この機能はAutomakeで提供す るものではありません.Automakeは`Makefile'の生成に焦点を絞るべき です.M4マクロの処理は,本当はAutoconfの仕事でしょう. aclocalを使用するためだけにAutomakeをインストールしていて, それ以外でのautomakeを使用しない人もいますが,それこそが,こ の機能が場違いであることを示しています.

新たな実装は,若干違うものになる可能性があります.例えば,ローカルなマクロの処理で議論した`m4/'形式の配置を強制し, `/usr/share/aclocal/'から持ってきたサードパーティーのマクロをこの ディレクトリにコピー(そして更新)するようになるかもしれません.

我々には,これがどうすれば良いか分かりません.このことは,これまでに何 度も議論されてきましたが,誰かがそのような不明確な作業を自分に科さなけ ればなりません.

ユーザの視点からは,aclocalの消滅は痛ましいものになり得ます. がたがたしないように切替えるための予防策があります.それは自分で aclocalを呼び出さないことです.こいつをautoreconf の制御下に追いやったり,Automakeのリビルドのルールにしたりしてください. 希望としては,aclocalが無くなったとき,すべての面倒が見られ ていて,崩壊後に悩む必要が無いようにしたいことでしょう.それ以外で,直 接,またはスクリプトからaclocalを呼び出している場合,変更に 注意して下さい.

aclocallibtoolizegettextizeまたは autopointautoconfautoheader,そして automakeを正しい順序で呼び出している,`bootstrap.sh'や `autogen.sh'といったスクリプトが一緒になっているパッケージもたく さんあります.実際,これはautoreconfでできることと全く同じで す.`bootstrap.sh'や`autogen.sh'のようなスクリプトがパッケー ジにある場合,autoreconfの使用を検討してみて下さい.それは論 理的にずいぶん簡単になり(管理には旨味はないけどね!),スクリプトはもは や不要で,aclocalを直接呼び出す場所も無くなります.

しばらくは,サードパーティのパッケージはパブリックマクロを /usr/share/aclocal/にインストールし続けるでしょう. aclocalが別のツールに置き換えられる場合,ディレクトリ名を変 更することに意味がありますが,すべてのマクロの後方互換性をより容易に提 供するため,/usr/share/aclocal/をサポートし続けるように書かれる ことになるでしょう(see section 独自のaclocalマクロを書く).


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Akihiro Sagawa on June, 8 2005 using texi2html 1.70.