| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Automakeは，パッケージに関する特定の情報を決定するために，パッケージの `configure.ac'をスキャンします．必要なautoconfマクロもあれ ば，`configure.ac'で定義する必要がある変数もあります．Automakeは， 出力物を調整するためにも，`configure.ac'からの情報を使用します．
Automakeは，管理をより容易にするためのAutoconfマクロも提供しています． これらのマクロは，aclocalプログラムを使用して自動的に `aclocal.m4'に書き込むことが可能です．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Automakeが本当に必要としていることは一つで，`configure.ac'でマク ロAM_INIT_AUTOMAKEを呼び出すことです．このマクロは，適切な Automakeの処理に必要なことをいくつか行ないます(see 節 5.6 Automakeが提供するAutoconfマクロ)．
Automakeは必要としますが，AM_INIT_AUTOMAKEで実行されないマクロ には，以下のものがあります．
AC_CONFIG_FILESAC_OUTPUTAC_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 が生成したものと考えません．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Automakeは実行されるたびに，`configure.ac'を追跡するために Autoconfを呼び出します．この方法で，特定のマクロの使用を認識し，生成さ れる`Makefile.in'を適切に調整します．現在認識されるマクロとそれら の効果は，以下のようになっています．
AC_CONFIG_HEADERSAM_CONFIG_HEADERの使用を要求していました (see 節 5.6 Automakeが提供するAutoconfマクロ)．これは今日では既に事実ではありません．
AC_CONFIG_LINKSmake distcleanで削 除し，make distの部分で生成される指名されたソースファイルを配布 するためのルールを生成します．
AC_CONFIG_AUX_DIR(スクリプトの完全なリストは以下のとおりです．`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 節 `Finding `configure' Input' in
AC_CONFIG_AUX_DIRで要求されるファイルは，このディレクトリに `Makefile.am'が無い場合でも自動的に配布されます．
AC_CANONICAL_HOSTAC_CANONICAL_SYSTEMAC_CANONICAL_HOSTに似ていますが，`Makefile'変数の `build_alias'と`target_alias'も定義します． See 節 `Getting the Canonical System Type' in
AC_LIBSOURCEAC_LIBSOURCESAC_LIBOBJAC_LIBSOURCEやAC_LIBSOURCESでリストアップさ れているすべてのファイルを自動的に配布します．
AC_LIBOBJSマクロがAC_LIBSOURCEを呼び出すことに注意してく ださい．そのため，AutoconfマクロがAC_LIBOBJ([file])を呼び出すと 説明されている場合，`file.c'はAutomakeで自動的に配布されます．こ れには，AC_FUNC_ALLOCA，AC_FUNC_MEMCMP， AC_REPLACE_FUNCS等の多くのマクロが含まれます．
ところで，直接LIBOBJSに代入することは，既にサポートされていませ ん．この目的では常にAC_LIBOBJを使用すべきです．See 節 `AC_LIBOBJ vs. LIBOBJS' in
AC_PROG_RANLIBAC_PROG_CXXAC_PROG_F77AC_F77_LIBRARY_LDFLAGSAC_PROG_FCAC_PROG_LIBTOOLlibtoolに対する処理を開始します(see 節 `Introduction' in
AC_PROG_YACCAC_PROG_LEXAC_SUBSTAutoconfマニュアルで，マクロがvarに対してAC_SUBSTを呼び出 すとか，出力変数varを定義するといった説明がある場合，varは それぞれのAutomakeが生成する`Makefile.in'で定義されます．例えば， AC_PATH_XTRAはX_CFLAGSとX_LIBSを定義するので， AC_PATH_XTRAが呼び出されている場合，`Makefile.am'でこれら 変数と使用することが可能です．
AM_C_PROTOTYPESAM_GNU_GETTEXTAM_MAINTAINER_MODEconfigureに`--enable-maintainer-mode'オプショ ンを加えます．これが使用されている場合，automakeは生成された `Makefile.in'内の`maintainer-only'ルールをデフォルトで停止し ます．このマクロは`MAINTAINER_MODE'条件を定義し，自分の `Makefile.am'で使用することが可能です．
m4_includem4_includeが`configure.ac'の著者によって使用されることは滅 多にありませんが，aclocalがパッケージローカルのファイルにあ るマクロを要求していることを検出したとき，`aclocal.m4'に現れるは ずです(システム全域のディレクトリにインストールされているマクロとは異 なります．5.3 aclocal.m4の自動生成を参照して下さい)．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Automakeには，パッケージで使用可能な多くのAutoconfマクロがあります (see 節 5.6 Automakeが提供するAutoconfマクロ)．状況によってはAutomakeが実際に必要とするものもありま す．これらのマクロは`aclocal.m4'で定義する必要があります．さもな ければ，それらはautoconfでは見つからないでしょう．
aclocalプログラムは，`configure.ac'の内容に基づいて自動的 に`aclocal.m4'ファイルを生成します．これは，Automakeが提供するマ クロを入手する便利な方法を提供し，それらを探し回る必要がないようになっ ています．aclocalのメカニズムで，他のパッケージに対して独自のマ クロを提供することも可能です(see 節 5.7 独自のaclocalマクロを書く)．また，カスタ ムマクロの独自セットを管理するためにそれを使用することも可能です (see 節 5.8 ローカルなマクロの処理)．
はじめに，aclocalはマクロ定義を探しながら見つかったすべての `.m4'ファイルをスキャンします(see 節 5.5 マクロ検索パス)．それか ら`configure.ac'をスキャンします．最初のステップで見つかったマク ロの記述によって，マクロとマクロが要求するファイルを`aclocal.m4' に書き込みます．
マクロ定義を含むファイルを`aclocal.m4'に書くことは，通常こ のファイルのテキスト全体を，`#'と`dnl'コメントを含め，未使用 のマクロまで含めてコピーすることで実行されます．aclocalがコメン トを完全に無視するようにしたい場合は，コメントの最初に`##'を使用 して下さい．
aclocalが選択しているファイルがaclocalの-I オプションで相対的なサーチパスで指定されているパッケージのサブディレク トリに存在するとき，aclocalはそのファイルがパッケージに属し ていると仮定し，`aclocal.m4'にコピーする代わりにm4_include を使用します．これで，パッケージはより小さくなり，依存性の追跡がより容 易になり，ファイルを自動的に配布物に含めるようになります．(例は， see 節 5.8 ローカルなマクロの処理．) システム全体で，または絶対パスで検索され見つかっ たマクロはコピーされます．そのため，外部パッケージとして考慮する必要が ある相対的なディレクトリがあるときは，-I reldirの代わりに -I `pwd`/reldirを使用して下さい．
`acinclude.m4'の内容も，このファイルが存在する場合は自動的に `aclocal.m4'に含められます．我々は，新しいパッケージでの `acinclude.m4'の使用に反対します(see 節 5.8 ローカルなマクロの処理)．
`aclocal.m4'を調べている間，実際に利用されているマクロを追跡し， 記述されているが要望されていないすべてのマクロを`aclocal.m4'から 削除するため，aclocalはautom4teを実行します(see 節 `Using Autom4te' in
autom4teはautoconfと同じPATHにあることを期待され ています．その場所は，AUTOM4TE環境変数を使用して優先させること が可能です．
5.4 aclocalのオプション Options supported by aclocal 5.5 マクロ検索パス How aclocal finds .m4 files
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
aclocalは，以下のオプションを受け入れます．
--acdir=dir--help-I dir--force--output=file--print-ac-diraclocalが検 索するディレクトリの名前を出力します．このオプションが与えられていると き，標準的な処理は行われません．このオプションは，パッケージがマクロファ イルをインストールする場所を決定するために使用することが可能です．
--verbose--version| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
デフォルトで，aclocalは`.m4'ファイルを以下のディレクト リで，この順番に探します．
acdir-APIVERSION1.6になります．
acdirautomake自身がビルドされるときにconfigureされます．これは `@datadir@/aclocal/'で，通常`${prefix}/share/aclocal/'に 展開されます．組み込みのacdirを知るために，--print-ac-dir オプションを使用してください．@end table
例として，automake-1.6.2が--prefix=/usr/localを用いてconfigure されたと仮定します．そのとき検索パスは以下のようになります．
(see 節 5.4 aclocalのオプション)で説明したように，この検索パスの変更や拡張で 使用可能なオプションもあります．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
--acdir
--acdir"へのコメント(無し)
検索パスを変更する最も明確なオプションは--acdir=dirで，デ フォルトのディレクトリを変更し，APIVERSIONディレクトリを取り消し ます．例えば，--acdir=/opt/private/を指定した場合，検索パスは以 下のようになります．
このオプション--acdirの目的は，automakeのテストスイートの内部で 使用することだけです．それはエンドユーザは通常不要です．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
-I dir
-Idir"へのコメント(無し)
-Iオプション(see 節 5.4 aclocalのオプション)を使用して，あらゆる追加ディ レクトリを指定することで，これらの検索リストに前置します．この ため，aclocal -I /foo -I /barは結果として以下のような検索パスに なります．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
検索パスをカスタマイズするため，三番目のメカニズムがあります． `dirlist'ファイルがacdirに存在する場合，そのファイルが，一 行ごとに検索リストに追加するディレクトリリストを含んでいると仮定されま す．これらのディレクトリは，すべての他のディレクトリの後に検索 されます．
例えば，`acdir/dirlist'が以下の内容を含んでいると仮定します．
/test1 /test2 |
そして，aclocalを-I /foo -I /barオプションで呼び出したと 仮定します．そのとき検索パスは以下のようになります．
--acdir=dirオプションが使用されている場合， aclocalは`dirlist'ファイルをdirで検索します．上記 の--acdir=/opt/private/の例では，aclocalは `/opt/private/dirlist'を探します．しかし，繰り返しますが， --acdirオプションの目的は，automakeのテストスイートの内部で使用 されることだけです．通常，--acdirはエンドユーザには不要です．
以下のような状況で，`dirlist'は役に立ちます．automakeのバー ジョン1.6.2が，`$prefix=/usr'でシステムベンダーによってイ ンストールされていると仮定します．このためデフォルトの検索ディレクトリ は以下のようになります．
しかし，システムには多くのパッケージが，いつも通りに `$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'
さて，システムに影響する"デフォルト"の検索パスは以下のようになります．
-Iオプションは不要です．-Iは，ローカルなシステム依存のツー ルのインストールディレクトリを回避するのではなく，プロジェクト独自のも のが必要な(`my-source-dir/m4/')として予約可能です．
同様に，Automakeのローカルコピーをアカウント内にインストールし， aclocalでシステムの他の場所にインストールされているマクロを 探したい場合，`dirlist'は手頃なはずです．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Automakeは，`configure.ac'で使用可能ないくつかのAutoconfマクロと ともに出荷されています．そのうちの一つを使用するとき，aclocalで `aclocal.m4'に含められるでしょう．
5.6.1 パブリックマクロ Macros that you can use. 5.6.2 プライベートマクロ Macros that you should not use.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
AM_CONFIG_HEADERAC_CONFIG_HEADERSと同じです (see 節 5.2 その他のAutomakeが理解すること)．
AM_ENABLE_MULTILIBAM_C_PROTOTYPESAM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTLTIOCGWINSZを使用するときに`GWINSZ_IN_SYS_IOCTLを定義します．それ以外の場合， TIOCGWINSZは`AM_INIT_AUTOMAKE([OPTIONS])AM_INIT_AUTOMAKE(PACKAGE, VERSION, [NO-DEFINE])このマクロには二つの形式があり，最初のものが好まれます．この形式では， AM_INIT_AUTOMAKEは単一の引数で呼び出されます -- ツリー内のすべ ての`Makefile.am'に適用するAutomakeオプションのスペースで分離され ているリストです．それぞれのオプションがAUTOMAKE_OPTIONSでリス トアップされているかの様な効果があります．
反対されている二番目のAM_INIT_AUTOMAKEの形式は，二つの引数が必 要です．パッケージとバージョンナンバーです．この形式は，package とversionが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_LISPDIRemacsプログラムを検索し，見つかった場合は，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_ASCCASを設定し， そして，必要な場合はCCASFLAGSも設定します．
AM_PROG_CC_C_OAC_PROG_CC_C_Oに似ていますが，それはautomakeが要求する形 式の結果を生成します．この機能が必要なときは，AC_PROG_CC_C_Oの 代わりにこれを使用して下さい．
AM_PROG_LEXAC_PROG_LEXに似ていますが(see 節 `Particular Program Checks' in
lex が無いシステムでmissingスクリプトを使用します．`HP-UX 10' はそのようなシステムの一つです．
AM_PROG_GCJgcjプログラムを見つけるか，そうでなければエラーを 発生します．それは`GCJ'と`GCJFLAGS'を設定します．gcj は，GNU Compiler CollectionのJavaフロントエンドです．
AM_SYS_POSIX_TERMIOSam_cv_sys_posix_termiosを`yes'に設定します． そうでない場合，その変数を`no'に設定します．
AM_WITH_DMALLOCWITH_DMALLOCを定義し，LIBSに `-ldmalloc'を加えます．
AM_WITH_REGEXconfigureコマンドラインに`--with-regex'を追加します．指定 されている(デフォルトの)場合，`regex'の正規表現ライブラリが使用さ れ，`regex.o'が`LIBOBJS'に書き込まれ，そして， `WITH_REGEX'が定義されます．`--without-regex'が与えられる場 合，`rx'正規表現ライブラリが使用され，`rx.o'が`LIBOBJS' に書き込まれます．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
以下のマクロは，直接呼び出すべきではないプライベートマクロです．それら は適切なときに他のパブリックマクロから呼び出されます．将来のバージョン で変更される可能性があるので，それらを呼び出さないでください．それらは 実装の詳細を考察するものと考えてください．または，何も考えないほうが良 いかもしれません．このセクションは読み飛ばしてください！
_AM_DEPENDENCIESAM_SET_DEPDIRAM_DEP_TRACKAM_OUTPUT_DEPENDENCY_COMMANDSAM_MAKE_INCLUDEmakeがinclude文を処理する方法を知 るために使用されます．それらは，必要なとき自動的に呼び出されます．手動 で呼び出す必然性はありません．
AM_PROG_INSTALL_STRIPstripするために使用可能な installのバージョンを知るために使用されます．このマクロは要求さ れるとき自動的にインクルードされます．
AM_SANITY_CHECKAM_INIT_AUTOMAKEから自動的に実行 されます．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
aclocalプログラムには，マクロ組み込みの知識が全く無いので， 独自のマクロでそれを拡張することは容易です．
これは，他のプログラムで使用する独自のAutoconfマクロを，供給したいライ ブラリに対して使用することが可能です．例えばgettextライブラリは， gettextを使用しているあらゆるパッケージで使用されるように， AM_GNU_GETTEXTマクロを提供しています．ライブラリがインストール されるとき，aclocalで見つかるように，このマクロをインストールし ます．
マクロファイルの名前は`.m4'で終わらせすべきです．そのようなファイ ルは`$(datadir)/aclocal'にインストールされます．簡単に書くと以下 のようになります．
aclocaldir = $(datadir)/aclocal aclocal_DATA = mymacro.m4 myothermacro.m4 |
マクロのファイルは，AC_DEFUN (see 節 `Macro Definitions' in
aclocalプログラムはAC_REQUIRE (see 節 `Prerequisite Macros' in
AC_PREREQの 呼び出しは，マクロ定義内部にすべきでファイルの最初に書くべきではありま せん．
Automake 1.8から，aclocalは，引用符で囲まれていない AC_DEFUNの呼び出しすべてに警告を発するようになっています．我々 はこれで，人々がうんざりすることを自覚していて，それは aclocalはこれまであまり厳密ではなく，多くのサードパーティー のマクロは引用符で囲まれていないためです．そして我々は，この一時的な不 便さを謝罪しなければなりません．我々が厳密にする必要がある理由は，将来 のaclocal (see 節 5.9 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 ローカルなマクロの処理を参照して下さい．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
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 節 `Using autoreconf to Update `configure' Scripts' in
autopoint (see 節 `Invoking the autopoint Program' in
gettextize (see 節 `Invoking the gettextize Program' in
ACLOCAL_AMFLAGSを定義す べきです．
aclocal -I m4が実行されるとき，要求されているマクロが定義されて いる`m4/'のあらゆるファイルをm4_includeし， aclocal.m4をビルドします．ローカルに見つからないマクロは， 5.5 マクロ検索パスで説明されているシステム全体のディレクトリで検 索されます．
カスタムマクロは`configure.ac'と同じ理由で配布すべきです．パッケー ジを動作させたい人は，そのすべてのファイルを持っているようにすべきです． 実際これは，すべてのm4_includeされるファイルが配布されるので， 自動的に配布されます．
しかし，パッケージで使用しているサードパーティーのマクロの配布には一致 している見解はありません．多くのライブラリは，独自のマクロをシステム全 体のaclocalディレクトリ(see 節 5.7 独自の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/'ディレクトリにコピーすることです．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
aclocalの将来aclocalの将来"へのコメント(無し)
aclocalの消滅が予想されています．この機能はAutomakeで提供す るものではありません．Automakeは`Makefile'の生成に焦点を絞るべき です．M4マクロの処理は，本当はAutoconfの仕事でしょう． aclocalを使用するためだけにAutomakeをインストールしていて， それ以外でのautomakeを使用しない人もいますが，それこそが，こ の機能が場違いであることを示しています．
新たな実装は，若干違うものになる可能性があります．例えば，5.8 ローカルなマクロの処理で議論した`m4/'形式の配置を強制し， `/usr/share/aclocal/'から持ってきたサードパーティーのマクロをこの ディレクトリにコピー(そして更新)するようになるかもしれません．
我々には，これがどうすれば良いか分かりません．このことは，これまでに何 度も議論されてきましたが，誰かがそのような不明確な作業を自分に科さなけ ればなりません．
ユーザの視点からは，aclocalの消滅は痛ましいものになり得ます． がたがたしないように切替えるための予防策があります．それは自分で aclocalを呼び出さないことです．こいつをautoreconf の制御下に追いやったり，Automakeのリビルドのルールにしたりしてください． 希望としては，aclocalが無くなったとき，すべての面倒が見られ ていて，崩壊後に悩む必要が無いようにしたいことでしょう．それ以外で，直 接，またはスクリプトからaclocalを呼び出している場合，変更に 注意して下さい．
aclocal，libtoolize，gettextizeまたは autopoint，autoconf，autoheader，そして automakeを正しい順序で呼び出している，`bootstrap.sh'や `autogen.sh'といったスクリプトが一緒になっているパッケージもたく さんあります．実際，これはautoreconfでできることと全く同じで す．`bootstrap.sh'や`autogen.sh'のようなスクリプトがパッケー ジにある場合，autoreconfの使用を検討してみて下さい．それは論 理的にずいぶん簡単になり(管理には旨味はないけどね！)，スクリプトはもは や不要で，aclocalを直接呼び出す場所も無くなります．
しばらくは，サードパーティのパッケージはパブリックマクロを /usr/share/aclocal/にインストールし続けるでしょう． aclocalが別のツールに置き換えられる場合，ディレクトリ名を変 更することに意味がありますが，すべてのマクロの後方互換性をより容易に提 供するため，/usr/share/aclocal/をサポートし続けるように書かれる ことになるでしょう(see 節 5.7 独自のaclocalマクロを書く)．
| [ << ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |