[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Automakeは,パッケージに関する特定の情報を決定するために,パッケージの
`configure.ac'をスキャンします.必要なautoconf
マクロもあれ
ば,`configure.ac'で定義する必要がある変数もあります.Automakeは,
出力物を調整するためにも,`configure.ac'からの情報を使用します.
Automakeは,管理をより容易にするためのAutoconfマクロも提供しています.
これらのマクロは,aclocal
プログラムを使用して自動的に
`aclocal.m4'に書き込むことが可能です.
5.1 コンフィグレーションの必要条件 | Configuration requirements | |
5.2 その他のAutomakeが理解すること | Other things Automake recognizes | |
5.3 aclocal.m4の自動生成 | Auto-generating aclocal.m4 | |
5.4 aclocalのオプション | aclocal command line arguments | |
5.5 マクロ検索パス | Modifying aclocal's search path | |
5.6 Automakeが提供するAutoconfマクロ | Autoconf macros supplied with Automake | |
5.7 独自のaclocalマクロを書く | Writing your own aclocal macros | |
5.8 ローカルなマクロの処理 | Organizing local macros | |
5.9 aclocal の将来 | aclocal's scheduled death |
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
が生成したものと考えません.
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_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 (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_XTRA
はX_CFLAGS
とX_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の自動生成を参照して下さい).
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'から
削除するため,aclocal
はautom4te
を実行します(see (autoconf)Using autom4te section `Using Autom4te
' in The Autoconf Manual).
autom4te
はautoconf
と同じPATH
にあることを期待され
ています.その場所は,AUTOM4TE
環境変数を使用して優先させること
が可能です.
5.4 aclocalのオプション | Options supported by aclocal | |
5.5 マクロ検索パス | How aclocal finds .m4 files |
aclocal
は,以下のオプションを受け入れます.
--acdir=dir
インストールされたディレクトリの代わりに,dirでマクロファイルを 探します.これは,通常デバッグで使用します.
--help
コマンドラインオプションの概要を出力し,終了します.
-I dir
`.m4'ファイルを探すディレクトリのリストに,dirディレクトリ を追加します.
--force
出力ファイルを常に上書きします.デフォルトは,必要なときだけ,すなわち その内容が変更されたときや,その依存元がより新しい場合,出力ファイルを 上書きします.
--output=file
`aclocal.m4'の代わりに,fileに出力を書き込みます.
--print-ac-dir
サードパーティーの`.m4'ファイルを見つけるためにaclocal
が検
索するディレクトリの名前を出力します.このオプションが与えられていると
き,標準的な処理は行われません.このオプションは,パッケージがマクロファ
イルをインストールする場所を決定するために使用することが可能です.
--verbose
調査しているファイルの名前を出力します.
--version
Automakeのバージョンナンバーを出力し,終了します.
デフォルトで,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
されたと仮定します.そのとき検索パスは以下のようになります.
`/usr/local/share/aclocal-1.6/'
`/usr/local/share/aclocal/'
(see section aclocalのオプション)で説明したように,この検索パスの変更や拡張で 使用可能なオプションもあります.
--acdir
検索パスを変更する最も明確なオプションは--acdir=dir
で,デ
フォルトのディレクトリを変更し,APIVERSIONディレクトリを取り消し
ます.例えば,--acdir=/opt/private/
を指定した場合,検索パスは以
下のようになります.
`/opt/private/'
このオプション--acdir
の目的は,automakeのテストスイートの内部で
使用することだけです.それはエンドユーザは通常不要です.
-I dir
-I
オプション(see section aclocalのオプション)を使用して,あらゆる追加ディ
レクトリを指定することで,これらの検索リストに前置します.この
ため,aclocal -I /foo -I /bar
は結果として以下のような検索パスに
なります.
`/foo'
`/bar'
acdir-APIVERSION
acdir
検索パスをカスタマイズするため,三番目のメカニズムがあります. `dirlist'ファイルがacdirに存在する場合,そのファイルが,一 行ごとに検索リストに追加するディレクトリリストを含んでいると仮定されま す.これらのディレクトリは,すべての他のディレクトリの後に検索 されます.
例えば,`acdir/dirlist'が以下の内容を含んでいると仮定します.
/test1 /test2 |
そして,aclocal
を-I /foo -I /bar
オプションで呼び出したと
仮定します.そのとき検索パスは以下のようになります.
`/foo'
`/bar'
acdir-APIVERSION
acdir
`/test1'
`/test2'
--acdir=dir
オプションが使用されている場合,
aclocal
は`dirlist'ファイルをdirで検索します.上記
の--acdir=/opt/private/
の例では,aclocal
は
`/opt/private/dirlist'を探します.しかし,繰り返しますが,
--acdir
オプションの目的は,automakeのテストスイートの内部で使用
されることだけです.通常,--acdir
はエンドユーザには不要です.
以下のような状況で,`dirlist'は役に立ちます.automake
のバー
ジョン1.6.2
が,`$prefix=/usr'でシステムベンダーによってイ
ンストールされていると仮定します.このためデフォルトの検索ディレクトリ
は以下のようになります.
`/usr/share/aclocal-1.6/'
`/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'
さて,システムに影響する"デフォルト"の検索パスは以下のようになります.
`/usr/share/aclocal-1.6/'
`/usr/share/aclocal/'
`/usr/local/share/aclocal/'
-I
オプションは不要です.-I
は,ローカルなシステム依存のツー
ルのインストールディレクトリを回避するのではなく,プロジェクト独自のも
のが必要な(`my-source-dir/m4/')として予約可能です.
同様に,Automakeのローカルコピーをアカウント内にインストールし,
aclocal
でシステムの他の場所にインストールされているマクロを
探したい場合,`dirlist'は手頃なはずです.
Automakeは,`configure.ac'で使用可能ないくつかのAutoconfマクロと
ともに出荷されています.そのうちの一つを使用するとき,aclocal
で
`aclocal.m4'に含められるでしょう.
5.6.1 パブリックマクロ | Macros that you can use. | |
5.6.2 プライベートマクロ | Macros that you should not use. |
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
の形式は,二つの引数が必
要です.パッケージとバージョンナンバーです.この形式は,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_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'
に書き込まれます.
以下のマクロは,直接呼び出すべきではないプライベートマクロです.それら は適切なときに他のパブリックマクロから呼び出されます.将来のバージョン で変更される可能性があるので,それらを呼び出さないでください.それらは 実装の詳細を考察するものと考えてください.または,何も考えないほうが良 いかもしれません.このセクションは読み飛ばしてください!
_AM_DEPENDENCIES
AM_SET_DEPDIR
AM_DEP_TRACK
AM_OUTPUT_DEPENDENCY_COMMANDS
これらのマクロはAutomakeの自動的な依存性の追跡手法を実装するために使用 されます.それらは,要求されたときAutomakeから自動的に呼び出され,手動 で呼び出す必然性はありません.
AM_MAKE_INCLUDE
このマクロは,ユーザのmake
がinclude
文を処理する方法を知
るために使用されます.それらは,必要なとき自動的に呼び出されます.手動
で呼び出す必然性はありません.
AM_PROG_INSTALL_STRIP
これは,インストール時にプログラムをstrip
するために使用可能な
install
のバージョンを知るために使用されます.このマクロは要求さ
れるとき自動的にインクルードされます.
AM_SANITY_CHECK
これは,ビルドディレクトリに作成されるファイルがソースディレクトリのファ
イルより確実に新しいことを調査します.時計の設定が正しくないシステムで
失敗するはずです.このマクロはAM_INIT_AUTOMAKE
から自動的に実行
されます.
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
を一般的に使用するもう一つの状況は,パッケージローカ
ルのマクロを管理するときです.ローカルなマクロの処理を参照して下さい.
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/'ディレクトリにコピーすることです.
aclocal
の将来 aclocal
の消滅が予想されています.この機能はAutomakeで提供す
るものではありません.Automakeは`Makefile'の生成に焦点を絞るべき
です.M4マクロの処理は,本当はAutoconfの仕事でしょう.
aclocal
を使用するためだけにAutomakeをインストールしていて,
それ以外でのautomake
を使用しない人もいますが,それこそが,こ
の機能が場違いであることを示しています.
新たな実装は,若干違うものになる可能性があります.例えば,ローカルなマクロの処理で議論した`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 section 独自のaclocalマクロを書く).
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Akihiro Sagawa on June, 8 2005 using texi2html 1.70.