\input texinfo   @c -*-texinfo-*-
@c %**start of header
@setfilename automake-ja.info
@settitle automake
@setchapternewpage off
@c %**end of header

@include automake-v.texi

@dircategory GNU admin
@direntry
* automake: (automake).		Makefile.inの作成
@end direntry

@dircategory Individual utilities
@direntry
* aclocal: (automake)Invoking aclocal.          aclocal.m4の生成
@end direntry

@ifinfo
This file documents GNU automake @value{VERSION}

Copyright (C) 1995, 96, 97, 98 Free Software Foundation, Inc.

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

@ignore
Permission is granted to process this file through TeX and print the
results, provided the printed document carries copying permission
notice identical to this one except for the removal of this paragraph


@end ignore
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation approved
by the Foundation.
@end ifinfo


@titlepage
@title GNU Automake
@subtitle For version @value{VERSION}, @value{UPDATED}
@author David MacKenzie and Tom Tromey (原著)
@author OKUJI Yoshinori (翻訳)

@page
@vskip 0pt plus 1filll
Copyright @copyright{} 1995, 96 Free Software Foundation, Inc.
@sp 2
This is the first edition of the GNU Automake documentation,@*
and is consistent with GNU Automake @value{VERSION}.@*
@sp 2
Published by the Free Software Foundation @*
59 Temple Place - Suite 330, @*
Boston, MA 02111-1307 USA @*

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation
approved by the Free Software Foundation.
@end titlepage

@c Define an index of configure variables.
@defcodeindex cv
@c Define an index of options.
@defcodeindex op
@c Define an index of targets.
@defcodeindex tr

@c Put everything in one index (arbitrarily chosen to be the concept index).
@syncodeindex cv cp
@syncodeindex op cp
@syncodeindex tr cp
@syncodeindex vr cp

@c @ifinfo
@ifnottex
@node Top, Introduction, (dir), (dir)
@comment  node-name,  next,  previous,  up
@top GNU Automake

このファイルではテンプレート・ファイルからGNU準拠のMakefileを生成するた
めのGNU Automakeパッケージを解説している。この版ではversion
@value{VERSION}について解説している。

@menu
* Introduction::                Automakeの目的
* Generalities::                全般的な概念
* Examples::                    いくつかの見本パッケージ
* Invoking Automake::           Makefile.inの作成
* configure::                   configure.inの検査
* Top level::                   一番上のMakefile.am
* Programs::                    プログラムやライブラリの構築
* Other objects::               他の派生したオブジェクト
* Other GNU Tools::             他のGNUツール
* Documentation::               解説書の構築
* Install::                     何がインストールされるか
* Clean::                       何がクリーンされるか
* Dist::                        何が配布物に含まれるか
* Tests::                       テストのサポート
* Options::                     Automakeの挙動の変更
* Miscellaneous::               雑多な規則
* Conditionals::                条件文
* Gnits::                       @code{--gnu}と@code{--gnits}の影響
* Cygnus::                      @code{--cygnus}の影響
* Extending::                   Automakeの拡張
* Distributing::                Makefile.inの配布
* Future::                      将来の考え
* Index::                       全体の索引

 --- The Detailed Node Listing ---

全般的な概念

* General Operation::           Automakeの全般的な操作
* Depth::                       パッケージの種類
* Strictness::                  標準適合性の点検
* Uniform::                     一定の名付け方
* Canonicalization::            派生した変数の名付け方

いくつかの見本パッケージ

* Complete::                    簡単な例、始めから終わりまで
* Hello::                       模範的なプログラム
* etags::                       etagsとctagsの構築

@file{configure.in}の検査

* Requirements::                設定の必要なもの
* Optional::                    Automakeが認識する他のもの
* Invoking aclocal::            aclocal.m4の自動生成
* Macros::                      Automakeと共に与えられるAutoconfのマクロ
* Extending aclocal::           あなた自身のaclocalマクロの記述

プログラムやライブラリの構築

* A Program::                   プログラムの構築
* A Library::                   ライブラリの構築
* LIBOBJS::                     LIBOBJSとALLOCAの特殊処理
* A Shared Library::            Libtoolライブラリの構築
* Program variables::           プログラムを構築するときに使用される変数
* Yacc and Lex::                YaccとLexのサポート
* C++::                         C++や他の言語
* ANSI::                        自動的な脱ANSI化
* Dependencies::                自動的な依存関係の追跡

他の派生したオブジェクト

* Scripts::                     実行可能なスクリプト
* Headers::                     ヘッダ・ファイル
* Data::                        アーキテクチャ独立なデータ・ファイル
* Sources::                     派生したソース

他のGNUツール

* Emacs Lisp::                  Emacs Lisp
* gettext::                     Gettext
* Guile::                       Guile
* Libtool::                     Libtool
* Java::                        Java

解説書の構築

* Texinfo::                     Texinfo
* Man pages::                   manページ

雑多な規則

* Tags::                        etagsとmkidのインターフェース
* Suffixes::                    新しいファイル拡張子の扱い
@end menu

@c @end ifinfo
@end ifnottex

@node Introduction, Generalities, Top, Top
@chapter 導入

Automakeは@file{Makefile.am}と名付けられるファイルから@file{Makefile.in}
を自動的に生成するためのツールである。各@file{Makefile.am}は基本的に(と
きどき規則が差し挟まれた)一連の@code{make}マクロ定義である。生成された
@file{Makefile.in}はGNU Makefile標準に適合する。

GNU Makefile標準の解説
(@pxref{Makefile Conventions, , , standards, The GNU Coding Standards})
は長くて、複雑で、変更を受けやすい。Automakeの目的は個々のGNU管理者の背
中からMakefile管理の重荷を取り除く(そしてそれをAutomake管理者の背中に置
く)ことである。

典型的なAutomakeの入力ファイルは単に一連のマクロ定義だけである。そのよう
なファイルはそれぞれ@file{Makefile.in}を作成するために処理される。一般的
にプロジェクトのディレクトリあたり一つの@file{Makefile.am}があるべきだ。

Automakeはプロジェクトをある方法に強制する。例えば、そのプロジェクトが
Autoconf(@pxref{Top, , The Autoconf Manual, autoconf, The Autoconf
Manual})を使うとみなし、@file{configure.in}の中身にある制限を加える。

Automakeは@file{Makefile.in}を生成するために@code{perl}を必要とする。し
かし、Automakeによって作成された配布物は完全にGNU準拠であり、構築するた
めに@code{perl}を必要としない。

Automakeへの提案やバグ報告は@email{automake-bugs@@gnu.org}にメールしなさ
い@footnote{訳注: この翻訳に関しては@email{okuji@@kuicr.kyoto-u.ac.jp}ま
で。}。


@node Generalities, Examples, Introduction, Top
@chapter 全般的な概念

Automakeがどう働くかを理解するのを助ける、2、3の基本的な概念がある。

@menu
* General Operation::           Automakeの全般的な操作
* Depth::                       パッケージの種類
* Strictness::                  標準適合性の点検
* Uniform::                     一定の名付け方
* Canonicalization::            派生した変数の名付け方
@end menu

@node General Operation, Depth, Generalities, Generalities
@section 全般的な操作

Automakeは@file{Makefile.am}を読み、@file{Makefile.in}を生成することで働
く。@file{Makefile.am}で定義される特定のマクロやターゲットはautomakeにもっ
と特化したコードを生成するよう指示する。例えば、@samp{bin_PROGRAMS}マク
ロ定義はコンパイルしリンクするためのターゲットを生成させるだろう。

@file{Makefile.am}のマクロ定義やターゲットは生成されたファイルにコピーさ
れる。こうして任意のコードを生成される@file{Makefile.in}に加えることがで
きる。例えば、Automakeの配布物は標準的でない@code{cvs-dist}ターゲットを
含み、それはAutomake管理者が彼のソース管理システムから配布物を作成するの
に使用されるのだ。

GNUのmake拡張はAutomakeによって認識されないことを注意せよ。
@file{Makefile.am}でそのような拡張を使用すれば、エラーや混乱させる振る
舞いを引き起こすだろう。

Automakeは隣接するターゲット(あるいは変数定義)のコメントを賢いやり方で集
めようとする。

@file{Makefile.am}で定義されるターゲットは一般的に@code{automake}によっ
て自動的に生成される同じ名前のターゲットを上書きする。これはサポートされ
ている特徴だが、ときどき生成される規則は非常に特殊なので、一般的にその使
用を避けるのが最善である。

同様に、@file{Makefile.am}で定義される変数は@code{automake}が通常生成す
る変数の定義を上書きするだろう。この特徴はターゲット定義を上書きする能力
よりも頻繁に役立つ。@code{automake}によって生成される変数の多くは内部利
用だけのためであると想定されており、それらの名前は将来のリリースで変更さ
れるかもしれないことに注意しなさい。

変数定義を調べるとき、Automakeはその定義で参照される変数を再帰的に調べる
だろう。例えば、Automakeが次のコード片で@samp{foo_SOURCES}の中身を見てい
るなら、

@example
xs = a.c b.c
foo_SOURCES = c.c $(xs)
@end example

@samp{foo_SOURCES}の中身として@file{a.c}、@file{b.c}、@file{c.c}というファ
イルを使用するだろう。

Automakeはまた出力にコピー@emph{されない}コメントの形式を許す。@samp{##}
で始まる全ての行はAutomakeに完全に無視される。

@file{Makefile.am}の最初の行にこう書いておくのが慣習である。

@example
## Process this file with automake to produce Makefile.in
@end example

@c FIXME discuss putting a copyright into Makefile.am here?  I would but
@c I don't know quite what to say.

@c FIXME document customary ordering of Makefile.am here!



@node Depth, Strictness, General Operation, Generalities
@section 深さ

@code{automake}は三つの種類のディレクトリ階層、``flat''、``shallow''、そ
して``deep''をサポートする。

@dfn{flat}パッケージは全てのファイルが単一のディレクトリにあるようなもの
である。そのようなパッケージの@file{Makefile.am}は定義により
@code{SUBDIRS}マクロがない。そのようなパッケージの例は@code{termutils}で
ある。
@vindex SUBDIRS

@dfn{deep}パッケージは全てのソースがサブディレクトリにあるようなものであ
る。その一番上の階層のディレクトリは主に設定情報を含んでいる。GNU cpioは
GNU @code{tar}と同じく、そのようなパッケージの良い例である。deepパッケー
ジの一番上の階層の@file{Makefile.am}は@code{SUBDIRS}マクロを含むだろうが、
構築されるオブジェクトを定義するための他のマクロは含まない。

@dfn{shallow}パッケージは主要なソースが一番上の階層のディレクトリにある
が、さまざまな部分(典型的にはライブラリ)がサブディレクトリにあるような
ものである。Automakeは(GNU @code{make}、それは現在@code{automake}を使っ
ていないが、それと同じく)そのようなパッケージの一つである。


@node Strictness, Uniform, Depth, Generalities
@section 厳密さ

AutomakeはGNUパッケージの管理者によって使われることを意図しているが、そ
れを使いたいけどGNUの慣習を全て使いたいわけではない人々に便宜をはかるた
めに、いくらか努力している。

この目標に対し、Automakeは@dfn{strictness}---どれぐらい厳密にAutomakeが
標準適合性を点検すべきかを示す正確さ---の三つの階層をサポートしている。

有効なstrictnessの階層は次のようである。

@table @samp
@item foreign
Automakeは適切な操作に絶対に必要とされるものだけを点検するだろう。例えば、
GNU標準は@file{NEWS}ファイルの存在を命じているけれども、この様式では必要
とされないだろう。その名前はAutomakeはGNUプログラムに対して使われること
を意図されているという事実に由来している。これらの緩和された規則は標準的
な様式の操作ではない。

@item gnu
AutomakeはパッケージがGNU標準に一致することを---可能な限りたくさん---点
検するだろう。これがデフォルトである。

@item gnits
Automakeはまだ書かれていないGnits標準に一致することを点検するだろう。こ
れらはGNU標準に基いているが、もっと詳細でさえある。あなたがGnits標準の寄
付者でないなら、Gnits標準が実際に公表されるようなときまでこのオプション
を避けることが推奨される。
@end table

strictnessの階層の精密な意味についてもっと情報を得るために、@xref{Gnits}
を見なさい。


@node Uniform, Canonicalization, Strictness, Generalities
@section 一定の名付け方

一般的にAutomake変数はどうプログラム(や他の派生したオブジェクト)が構築さ
れ、どうそれらがインストールされるのか決定するのが簡単にする一定の名付け
方に従う。この方法はまた何が構築されるべきかに関する@code{configure}時の
決定もサポートしている。

@code{make}のときに、特定の変数がどのオブジェクトが構築されるのかを決定
するために使われる。例えば、主要な変数@code{PROGRAMS}はコンパイルされリ
ンクされるプログラムのリストを保持する。
@vindex PROGRAMS

異なる変数の組が構築されたオブジェクトがどこにインストールされるべきかを
決めるのに使われる。これらの変数は主要な変数にちなんで名付けられているが、
どの標準ディレクトリがインストールのディレクトリとして使われるべきかを示
す接頭辞を持っている。標準ディレクトリ名はGNU標準(@pxref{Directory
Variables, , , standards, The GNU Coding Standards})で与えられている。
Automakeはこのリストを@code{pkglibdir}、@code{pkgincludedir}と
@code{pkgdatadir}で拡張する。これらは@samp{pkg}でないバージョンと同じだ
が、@samp{@@PACKAGE@@}が追加されている。例えば、@code{pkglibdir}は
@code{$(datadir)/@@PACKAGE@@}と定義されている@footnote{訳注:
@code{$(libdir)/@@PACKAGE@@}の間違いだろう。}。
@cvindex PACKAGE

各主要変数に対し、主要変数名に@samp{EXTRA_}を頭に付けて名付けられた、追
加の変数がある。この変数は@code{configure}が決定するものに依存して、構築
されたりされなかったりするオブジェクトを列挙するために使われる。あらゆる
場合に働く@file{Makefile.in}を生成するために、Automakeは構築されるオブジェ
クトのリスト全体を静的に知っていなければならないので、この変数は必要とさ
れる。

例えば、@code{cpio}はどのプログラムが構築されるか設定時に決定する。プロ
グラムの一部は@code{bindir}にインストールされるし、一部は@code{sbindir}
にインストールされる。

@example
EXTRA_PROGRAMS = mt rmt
bin_PROGRAMS = cpio pax
sbin_PROGRAMS = @@PROGRAMS@@
@end example

(@code{PROGRAMS}のように)接頭辞なしに主要な変数を定義するのは誤りである。

変数名を組み立てるとき、共通の@samp{dir}接尾辞が除かれることに注意せよ。
こうして@samp{bin_PROGRAMS}と書き、@samp{bindir_PROGRAMS}とは書かない。

あらゆる種類のオブジェクトがあらゆるディレクトリにインストールされ得るわ
けではない。Automakeはエラーになる、そのような試みを止めるだろう。
Automakeはまたディレクトリ名の明らかな綴り違いを診断するだろう。

ときどき標準のディレクトリは---Automakeによって補強されてさえ---十分ではな
い。とりわけ、明瞭さのために、ある先に定義されたディレクトリのサブディレ
クトリにオブジェクトをインストールすることがときどき有用である。この目的
のために、Automakeは可能なインストール用ディレクトリのリストを拡張できる
ようにしている。任意の接頭辞(例えば@samp{zar})はもし@samp{dir}が付けられ
た同じ名前の変数が定義されていれば(例えば@samp{zardir})有効である。

例えば、HTMLサポートがAutomakeの一部となるまで、生のHTML文書をインストー
ルために次のように使用できる。

@example
htmldir = $(prefix)/html
html_DATA = automake.html
@end example

特別な接頭辞@samp{noinst}は問題となっているオブジェクトが全くインストー
ルされるべきでないことを表す。

特別な接頭辞@samp{check}は問題となっているオブジェクトが@code{make
check}コマンドが走らされるまで構築されるべきでないことを表す。

可能な主要名は@samp{PROGRAMS}、@samp{LIBRARIES}、@samp{LISP}、
@samp{SCRIPTS}、@samp{DATA}、@samp{HEADERS}、@samp{MANS}、そして
@samp{TEXINFOS}である。
@vindex PROGRAMS
@vindex LIBRARIES
@vindex LISP
@vindex SCRIPTS
@vindex DATA
@vindex HEADERS
@vindex MANS
@vindex TEXINFOS


@node Canonicalization,  , Uniform, Generalities
@section 派生した変数の名付け方

ときどきMakefile変数名はユーザが与えるあるテキストに由来している。例えば、
プログラム名はMakefileマクロ名に書き直される。Automakeはこのテキストが
Makefile変数名の規則に従わなくても良いように、それを正規化する。マクロ参
照を行うとき、英字、数字、アンダースコアを除く、その名前の全ての文字がア
ンダースコアに変換される。例えば、もしあなたのプログラムが
@code{sniff-glue}と名付けられているなら、派生する変数名は
@code{sniff_glue_SOURCES}で、@code{sniff-glue_SOURCES}ではない。


@node Examples, Invoking Automake, Generalities, Top
@chapter いくつかの見本パッケージ

@menu
* Complete::                    簡単な例、始めから終わりまで
* Hello::                       模範的なプログラム
* etags::                       etagsとctagsの構築
@end menu

@node Complete, Hello, Examples, Examples
@section 簡単な例、始めから終わりまで

あなたはちょうど、あなたの頭を渦から渦へ漂わせるプログラム@footnote{訳注:
何だこりゃ。原文は、a program to make your head float from vortex to
vortex. }、@code{zardoz}を書き終わったところだと想像しよう。移植性のある
枠組を提供するために@code{autoconf}を使っているが、あなたの
@file{Makefile.in}はその場限りである。あなたはそれらをがっちりさせたいの
で、@code{automake}に切り換える。

最初の段階は@code{automake}が必要とするコマンドを含むように、あなたの
@file{configure.in}を更新することである。これを行う一番簡単な方法は
@code{AC_INIT}のすぐ後に@code{AM_INIT_AUTOMAKE}呼び出しを加えることであ
る。

@example
AM_INIT_AUTOMAKE(zardoz, 1.0)
@end example

あなたのプログラムは面倒な要因を持っていない(例えば、@code{gettext}を使
わない、共有ライブラリを構築したがらない)ので、この部分は終了だ。ちょろ
かったね!

さて、@file{configure}を再生成しなければならない。しかし、これを行うため
に、あなたが使っている新しいマクロの発見法を@code{autoconf}に教える必要
があるだろう。これを行う一番簡単な方法はあなたのために@file{aclocal.m4}
を生成してくれる@code{aclocal}プログラムを使うことだ。でも待って... あな
たはあなたのプログラムのためにいくつかの毛だらけのマクロ@footnote{訳注:
何だ、この表現は？ some hairy macros}を書かなければならなかったので、す
でに@file{aclocal.m4}を持っている。@code{aclocal}はあなた自身のマクロを
@file{acinclude.m4}に入れさせるので、単に改名してから走らせる。

@example
mv aclocal.m4 acinclude.m4
aclocal
autoconf
@end example

さあ@code{zardoz}のために@file{Makefile.am}を書くときだ。@code{zardoz}は
ユーザ・プログラムなので、その他のユーザ・プログラムが入るところにインス
トールしたい。@code{zardoz}はまたTexinfo文書も持っている。あなたの
@file{configure.in}スクリプトは@code{AC_REPLACE_FUNCS}を使っているので、
@samp{@@LIBOBJS@@}とリンクする必要がある。だからこれがあなたが書くものだ。

@example
bin_PROGRAMS = zardoz
zardoz_SOURCES = main.c head.c float.c vortex9.c gun.c
zardoz_LDADD = @@LIBOBJS@@

info_TEXINFOS = zardoz.texi
@end example

さて、あなたの@file{Makefile.in}を生成し、必要かもしれない補助ファイルを
取ってくるために@code{automake --add-missing}を走らせればよい、そうすれば
完了だ!


@node Hello, etags, Complete, Examples
@section 模範的なプログラム

@code{hello}はその模範的な単純さと汎用性で高名である。この節ではAutomake
がどのようにHelloパッケージで使われ得たのかを示す。以下の例は最新のGNU
Helloに由来するが、著作権のコメント全てだけではなく、管理者用のみのコー
ドも全て除かれている。

もちろん、GNU Helloはあなたの伝統的な二行のものより幾分多くの特色を持っ
ている。GNU Helloは国際化されており、オプションの処理を行い、マニュアル
とテストの組を持っている。GNU Helloはdeepパッケージである。

ここにGNU Helloからの@file{configure.in}を見せる。

@example
dnl Process this file with autoconf to produce a configure script.
AC_INIT(src/hello.c)
AM_INIT_AUTOMAKE(hello, 1.3.11)
AM_CONFIG_HEADER(config.h)

dnl Set of available languages.
ALL_LINGUAS="de fr es ko nl no pl pt sl sv"

dnl Checks for programs.
AC_PROG_CC
AC_ISC_POSIX

dnl Checks for libraries.

dnl Checks for header files.
AC_STDC_HEADERS
AC_HAVE_HEADERS(string.h fcntl.h sys/file.h sys/param.h)

dnl Checks for library functions.
AC_FUNC_ALLOCA

dnl Check for st_blksize in struct stat
AC_ST_BLKSIZE

dnl internationalization macros
AM_GNU_GETTEXT
AC_OUTPUT([Makefile doc/Makefile intl/Makefile po/Makefile.in \
           src/Makefile tests/Makefile tests/hello],
   [chmod +x tests/hello])
@end example

@samp{AM_}マクロはAutomake(あるいはGettextライブラリ)によって提供され、
残りは標準的なAutoconfマクロである。


一番上層の@file{Makefile.am}。

@example
EXTRA_DIST = BUGS ChangeLog.O
SUBDIRS = doc intl po src tests
@end example

このように、ここでは全ての作業が実際にはサブディレクトリで行われる。

@file{po}と@file{intl}ディレクトリは@code{gettextize}を使って自動的に生
成される。それらはここでは論じない。

@file{doc/Makefile.am}ではこのようだ。

@example
info_TEXINFOS = hello.texi
hello_TEXINFOS = gpl.texi
@end example

これはHelloマニュアルを構築し、インストールし、配布するのに十分である。


ここに@file{tests/Makefile.am}を示す。

@example
TESTS = hello
EXTRA_DIST = hello.in testdata
@end example

スクリプト@file{hello}は@code{configure}に生成され、唯一のテスト問題であ
る。@code{make check}はこのテストを走らせるだろう。

最後は@file{src/Makefile.am}で、そこで本来の作業の全てが行われる。

@example
bin_PROGRAMS = hello
hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h 
hello_LDADD = @@INTLLIBS@@ @@ALLOCA@@
localedir = $(datadir)/locale
INCLUDES = -I../intl -DLOCALEDIR=\"$(localedir)\"
@end example


@node etags,  , Hello, Examples
@section etagsとctagsの構築

ここで別の、もっと巧妙な例を見せる。同じソース・ファイル(@file{etags.c})
から二つのプログラム(@code{ctags}と@code{etags})を生成する方法を示す。難
しい部分は@file{etags.c}のそれぞれのコンパイルに異なる@code{cpp}フラグを
必要とすることである。

@example
bin_PROGRAMS = etags ctags
ctags_SOURCES =
ctags_LDADD = ctags.o

etags.o: etags.c
        $(COMPILE) -DETAGS_REGEXPS -c etags.c

ctags.o: etags.c
        $(COMPILE) -DCTAGS -o ctags.o -c etags.c
@end example

@code{ctags_SOURCES}が空であると定義されていることに注意せよ---こうして
暗黙の値が代用されることはない。しかしながら、暗黙の値は@file{etags.o}か
ら@code{etags}を生成するために使われている。

@code{ctags_LDADD}は@file{ctags.o}をリンク行に入れるために使われる。
@code{ctags_DEPENDENCIES}はAutomakeによって生成される。

上記の規則はあなたのコンパイラが@samp{-c}と@samp{-o}を同時に受け取らない
なら上手く行かない。このための最も簡単な処置は(並列@code{make}での問題を
避けるために)にせものの依存関係を導入することである。

@example
etags.o: etags.c ctags.o
        $(COMPILE) -DETAGS_REGEXPS -c etags.c

ctags.o: etags.c
        $(COMPILE) -DCTAGS -c etags.c && mv etags.o ctags.o
@end example

また、これらの明示的な規則はもし非ANSIの特徴が使われていると上手く行かな
い。これをサポートするにはもう少しの作業が必要だ。

@example
etags._o: etags._c ctags.o
        $(COMPILE) -DETAGS_REGEXPS -c etags.c

ctags._o: etags._c
        $(COMPILE) -DCTAGS -c etags.c && mv etags._o ctags.o
@end example


@node Invoking Automake, configure, Examples, Top
@chapter @file{Makefile.in}の作成

あるパッケージの@file{Makefile.in}を全て作成するために、一番上層のディレ
クトリで引数を付けずに@code{automake}プログラムを走らせる。
@code{automake}は(@file{configure.in}を検査することで、
@pxref{configure})自動的にそれぞれの適切な@file{Makefile.am}を見付け、対
応する@file{Makefile.in}を生成するだろう。@code{automake}はパッケージを
構成するものに関してやや単純化し過ぎた見方をすることに注意せよ。パッケー
ジは最上位にたった一つの@file{configure.in}を持つとみなす。もしあなたの
パッケージが複数の@file{configure.in}を持っているなら、
@file{configure.in}を持つ各ディレクトリ毎に@code{automake}を走らせなけれ
ばならない。

@code{automake}に引数を与えても構わない。@samp{.am}がその引数に付け加え
られ、その結果が入力ファイルの名前として使用される。この特徴は一般的に古
くなっている@file{Makefile.in}を自動的に再構築するためにのみ使われる。あ
るサブディレクトリの@file{Makefile.in}を再生成するために使われる場合でさ
え、@code{automake}は常にプロジェクトの最高位のディレクトリから走らされ
なければならないことに注意せよ。@code{automake}は@file{configure.in}を検
査しなければならないし、@code{automake}はある場合にはその振る舞いを変更
するために@file{Makefile.in}はサブディレクトリにあるという情報を利用する
ので、これは必要である。

@code{automake}は以下のオプションを受け取る。

@table @code
@item -a
@itemx --add-missing
Automakeは特定の状況では特定の共通ファイルが存在することを必要とする。例
えば、@file{configure.in}が@code{AC_CANONICAL_HOST}を走らせるなら
@file{config.guess}が必要である。Automakeはこれらのファイルのいくつかと
共に配布されている。このオプションは可能ならいつでも、見付からないものを
パッケージに自動的に追加させる。概してAutomakeがあるファイルが欠けている
とあなたに教えたら、このオプションの使用を試みなさい。

@item --amdir=@var{dir}
Automakeのデータ・ファイルをインストールされたディレクトリではなく
ディレクトリ@var{dir}で探す。これは典型的にはデバッグのために使われる。

@item --build-dir=@var{dir}

Automakeにどこに構築ディレクトリがあるか知らせる。このオプションは
@code{make dist}によって生成された@file{Makefile.in}に依存関係を含めると
きに使われる。そうでなければ使われるべきでない。

@item --cygnus
生成される@file{Makefile.in}が、GNUやGnits規則ではなく、Cygnus規則に従う
ようにする。@xref{Cygnus}にもっと情報がある。

@item --foreign
広域的なstrictnessを@samp{foreign}に設定する。@xref{Strictness}にもっと
情報がある。

@item --gnits
広域的なstrictnessを@samp{gnits}に設定する。@xref{Gnits}にもっと情報があ
る。

@item --gnu
広域的なstrictnessを@samp{gnu}に設定する。@xref{Gnits}にもっと情報がある。
これがデフォルトのstrictnessである。

@item --help
コマンドラインのオプションのまとめを出力して終了する。

@item -i
@itemx --include-deps
生成された@file{Makefile.in}に自動的に生成された依存情報
(@pxref{Dependencies})の全てを含める。これは一般的に配布物を作るときに行
われる。@ref{Dist}を見よ。

@item --generate-deps
自動的に生成された依存情報(@pxref{Dependencies})の全てを一つのファイル、
@file{.dep_segment}に連結するファイルを生成する。これは一般に配布物を作
るときに行われる。@ref{Dist}を見よ。それは@file{SMakefile}や他のプラット
ホームのmakefile(@file{Makefile.DOS}など)を管理するときに有用である。
@code{--include-deps}、@code{--srcdir-name}、@code{--build-dir}と組み合
わせてだけ使うことができる。このオプションが与えられれば、他の処理は一切
行われないことに注意せよ。

@item --no-force
通常@code{automake}は@file{configure.in}で記述される@file{Makefile.in}を
全て作成する。このオプションは依存関係の一つに関して古くなっているような
@file{Makefile.in}だけを更新させる。

@item -o @var{dir}
@itemx --output-dir=@var{dir}
生成された@file{Makefile.in}をディレクトリ@var{dir}に置く。通常それぞれ
の@file{Makefile.in}は対応する@file{Makefile.am}のディレクトリに作成され
る。このオプションは配布物を作るときに使われる。

@item --srcdir-name=@var{dir}
Automakeに現在の構築に関連するソース・ディレクトリの名前を教える。このオ
プションは@code{make dist}によって生成された@file{Makefile.in}に依存関係
を含めるときに使われる。さもなければ使われるべきでない。

@item -v
@itemx --verbose
Automakeにどのファイルが読まれており、作成されているのか、情報を出力させ
る。

@item --version
Automakeのバージョン・ナンバーを出力し終了する。
@end table


@node configure, Top level, Invoking Automake, Top
@chapter @file{configure.in}の検査

Automakeはパッケージに関するある情報を決定するために、そのパッケージの
@file{configure.in}を検査する。@file{configure.in}には、いくつかの
@code{autoconf}マクロが必要とされ、いくつかの変数が定義されていなければ
ならない。Automakeはまたその出力を将来調整するために@file{configure.in}
からの情報を使用するだろう。

Automakeはまた管理を容易にするためにいくつかの@code{autoconf}マクロを与
える。これらのマクロは@code{aclocal}プログラムを使って、あなたの
@file{aclocal.m4}に自動的に配置することができる。

@menu
* Requirements::                設定の必要なもの
* Optional::                    Automakeが認識する他のもの
* Invoking aclocal::            aclocal.m4の自動生成
* Macros::                      Automakeと共に与えられるAutoconfのマクロ
* Extending aclocal::           あなた自身のaclocalマクロの記述
@end menu


@node Requirements, Optional, configure, configure
@section 設定の必要なもの

Automakeに必要な基本的なものを満たす最も簡単な方法はマクロ
@code{AM_INIT_AUTOMAKE}(@pxref{Macros})を使うことだ。しかし好むなら、手
で必要な処置を行うことができる。
@cvindex AM_INIT_AUTOMAKE

@itemize @bullet
@item
変数@code{PACKAGE}と@code{VERSION}を@code{AC_SUBST}で定義しなさい。
@cvindex PACKAGE
@cvindex VERSION
@code{PACKAGE}は配布物にまとめられるときに現れるような、パッケージの名前
であるべきだ。例えば、Automakeは@code{PACKAGE}を@samp{automake}であると
定義している。@code{VERSION}は開発されているそのリリースのバージョン・ナ
ンバーであるべきだ。@file{configure.in}をあなたのパッケージでバージョン・
ナンバーが定義される唯一の場所とすることを勧める。こうすればもっとリリー
スが簡単になる。

Automakeは@samp{Gnits}モード(@pxref{Gnits})以外では、@code{PACKAGE}や
@code{VERSION}の解釈を何も行わない。

@item
もしプログラムやスクリプトがインストールされるなら、マクロ
@code{AC_ARG_PROGRAM}を使う。
@cvindex AC_ARG_PROGRAM

@item
もしそのパッケージがflatでないなら、@code{AC_PROG_MAKE_SET}を使う。
@cvindex AC_PROG_MAKE_SET

@item
構築環境が健全であることを確かにするために@code{AM_SANITY_CHECK}を使いな
さい。

@item
もしパッケージによってスクリプト(@pxref{Scripts})がインストールされるな
ら、@code{AM_PROG_INSTALL}を使いなさい。そうでないなら、
@code{AC_PROG_INSTALL}を使いなさい。
@cvindex AC_PROG_INSTALL
@cvindex AM_PROG_INSTALL

@item
プログラム @code{aclocal}、@code{autoconf}、@code{automake}、
@code{autoheader}、@code{makeinfo}が構築環境にあるかどうかを調べるのに
@code{AM_MISSING_PROG}を使いなさい。ここでこれがどう行われるかを示す。
@example
missing_dir=`cd $ac_aux_dir && pwd`
AM_MISSING_PROG(ACLOCAL, aclocal, $missing_dir)
AM_MISSING_PROG(AUTOCONF, autoconf, $missing_dir)
AM_MISSING_PROG(AUTOMAKE, automake, $missing_dir)
AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir)
AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
@end example
@end itemize


Automakeが必要とするが@code{AM_INIT_AUTOMAKE}によって走らされない他のマ
クロはこのようである。

@table @code
@item AC_OUTPUT
Automakeはこれをどのファイルが作成されるのかを決定するのに使用する。
@code{Makefile}と名付けられた、列挙されたファイルは@file{Makefile}である
として扱われる。他の列挙されたファイルは異なる扱いを受ける。現在唯一の違
いは@file{Makefile}は@code{make distclean}によって削除されるが、他のファ
イルは@code{make clean}によって削除されることである。
@c FIXME: this is in violation of standards!
@cvindex AC_OUTPUT
@end table

@node Optional, Invoking aclocal, Requirements, configure
@section Automakeが認識する他のもの

Automakeはまた特定のマクロの使用を認識し、生成された@file{Makefile.in}を
適切に調整する。現在認識されるマクロとそれらの効果はこのようである。

@table @code
@item AC_CONFIG_HEADER
Automakeは@code{AM_CONFIG_HEADER}の使用を必要とするが、それは
@code{AC_CONFIG_HEADER}に似ているが、Automake特異的な有用な作業を行う。
@cvindex AC_CONFIG_HEADER

@item AC_CONFIG_AUX_DIR
Automakeは@file{mkinstalldirs}のような、さまざまな援助スクリプトをこのマ
クロの起動で名付けられたディレクトリで探す。もし見付からないと、スクリプ
トはそれらの``標準的な''場所(一番上のソース・ディレクトリか、現在の
@file{Makefile.am}に対応するソース・ディレクトリで、適切であればどちらで
も)で探される。
@cvindex AC_CONFIG_AUX_DIR
FIXME: give complete list of things looked for in this directory

@item AC_PATH_XTRA
Automakeは@code{AC_PATH_XTRA}によって定義される変数のための定義を、Cプロ
グラムやライブラリを構築する@file{Makefile.in}のそれぞれに挿入する。
@cvindex AC_PATH_XTRA

@item AC_CANONICAL_HOST
@itemx AC_CHECK_TOOL
Automakeは@file{config.guess}と@file{config.sub}が存在することを保証する
だろう。また、@file{Makefile}変数の@samp{host_alias}と
@samp{host_triplet}が導入される。
@c fixme xref autoconf docs.
@cvindex AC_CANONICAL_HOST
@cvindex AC_CHECK_TOOL
@vindex host_alias
@vindex host_triplet

@item AC_CANONICAL_SYSTEM
これは@code{AC_CANONICAL_HOST}に似ているが、@file{Makefile}変数の
@samp{build_alias}と@samp{target_alias}も定義する。
@cvindex AC_CANONICAL_SYSTEM
@vindex build_alias
@vindex target_alias

@item AC_FUNC_ALLOCA
@itemx AC_FUNC_GETLOADAVG
@itemx AC_FUNC_MEMCMP
@itemx AC_STRUCT_ST_BLOCKS
@itemx AC_FUNC_FNMATCH
@itemx AM_FUNC_STRTOD
@itemx AC_REPLACE_FUNCS
@itemx AC_REPLACE_GNU_GETOPT
@itemx AM_WITH_REGEX
Automakeは適切な依存関係がこれらのマクロに対応するオブジェクトに対して生
成されることを保証するだろう。また、Automakeは適切なソース・ファイルが配
布物に含まれていることを確認するだろう。Automakeはこれらのマクロを使用す
るために必要とされる、いかなるCソースとも配られていないので、
@code{automake -a}はそのソースをインストールしようとしないことに注意せよ。
@xref{A Library}にもっと情報がある。
@cvindex AC_FUNC_ALLOCA
@cvindex AC_FUNC_GETLOADAVG
@cvindex AC_FUNC_MEMCMP
@cvindex AC_STRUCT_ST_BLOCKS
@cvindex AC_FUNC_FNMATCH
@cvindex AC_FUNC_FNMATCH
@cvindex AC_REPLACE_FUNCS
@cvindex AC_REPLACE_GNU_GETOPT
@cvindex AM_FUNC_STRTOD
@cvindex AM_WITH_REGEX

@item LIBOBJS
Automakeは@samp{.o}ファイルを@code{LIBOBJS}に置く式を検出し、これらの追
加ファイルが@code{AC_REPLACE_FUNCS}によって見付けられたかのように扱うだ
ろう。
@cvindex LIBOBJS

@item AC_PROG_RANLIB
これはもしそのパッケージでライブラリが構築されるなら必要である。
@cvindex AC_PROG_RANLIB

@item AC_PROG_CXX
これはC++のソースが含まれているなら必要である。
@cvindex AC_PROG_CXX

@item AM_PROG_LIBTOOL
Automakeは@code{libtool}(@pxref{Top, , The Libtool Manual, libtool, The
Libtool Manual})を処理するようになるだろう。
@cvindex AM_PROG_LIBTOOL

@item AC_PROG_YACC
もしYaccのソース・ファイルが現れるなら、このマクロを使うか、
@file{configure.in}で変数@samp{YACC}を定義してなければならない。前者がよ
り好ましい。
@cvindex AC_PROG_YACC
@cvindex YACC

@item AC_DECL_YYTEXT
このマクロはもしそのパッケージにLexのソースがあるなら必要である。
@cvindex AC_DECL_YYTEXT

@item AC_PROG_LEX
もしLexのソース・ファイルが現れるなら、このマクロが使われなければならない。
@cvindex AC_PROG_LEX

@item ALL_LINGUAS
もしAutomakeがこの変数が@file{configure.in}で設定されていることを確認す
ると、名付けられた@samp{.po}ファイルが全て存在し、存在する@samp{.po}ファ
イルが全て名付けられていることを保証するために、@file{po}ディレクトリを
点検するだろう。
@cvindex ALL_LINGUAS

@item AM_C_PROTOTYPES
これは自動的な脱ANSI化を使うとき必要で、@ref{ANSI}を見なさい。
@cvindex AM_C_PROTOTYPES

@item AM_GNU_GETTEXT
このマクロはGNU gettext(@pxref{gettext})を使うパッケージに必要とされる。
それはgettextと配布されている。もしAutomakeがこのマクロを見付けると、
パッケージがgettextに必要なものの一部を満たすことを保証する。
@cvindex AM_GNU_GETTEXT

@item AM_MAINTAINER_MODE
このマクロは@code{configure}に@samp{--enable-maintainer-mode}オプション
を加える。これが使われれば、@code{automake}は生成される
@file{Makefile.in}でデフォルトでは``管理者専用''規則を無効にするだろう。
このマクロは@samp{Gnits}モード(@pxref{Gnits})では禁止されている。
@cvindex AM_MAINTAINER_MODE

@item AC_SUBST
@itemx AC_CHECK_TOOL
@itemx AC_CHECK_PROG
@itemx AC_CHECK_PROGS
@itemx AC_PATH_PROG
@itemx AC_PATH_PROGS
これらのマクロのそれぞれに対し、最初の引数が自動的に生成される
@file{Makefile.in}のそれぞれで変数として定義される。
@cvindex AC_SUBST
@cvindex AC_CHECK_TOOL
@cvindex AC_CHECK_PROG
@cvindex AC_CHECK_PROGS
@cvindex AC_PATH_PROG
@cvindex AC_PATH_PROGS

@end table


@node Invoking aclocal, Macros, Optional, configure
@section aclocal.m4の自動生成

Automakeはあなたのパッケージで使用可能なたくさんのAutoconfマクロを含んで
いる。それらの一部は特定の状況で実際にAutomakeによって必要とされる。これ
らのマクロはあなたの@file{aclocal.m4}で定義されていなければならない。そ
うでないと@code{autoconf}がそれらを発見できない。

@code{aclocal}プログラムは@file{configure.in}の中身に基いて自動的に
@file{aclocal.m4}ファイルを生成する。これによって、探し回らずにAutomake
が提供するマクロを簡便に得ることができる。また、@code{aclocal}の機構は他
のパッケージの利用に拡張可能である。

開始時に、@code{aclocal}は見付けられる全ての@samp{.m4}ファイルを検査し、
マクロ定義を探す。そして@file{configure.in}を検査する。最初の段階に見付
けたマクロの一つについて何らかの記述があれば、このマクロとそれがさらに必
要とするどのマクロも@file{aclocal.m4}に置かれる。

もしあれば、@file{acinclude.m4}の中身も@file{aclocal.m4}に自動的に入れら
れる。これはローカルなマクロを@file{configure}に組み入れるのに便利である。

@code{aclocal}は以下のオプションを受け取る。

@table @code
@item --acdir=@var{dir}
マクロ・ファイルをインストールされたディレクトリではなく@var{dir}で探す。
これは典型的にはデバッグのために使われる。

@item --help
コマンドラインのオプションのまとめを出力し終了する。

@item -I @var{dir}
@samp{.m4}ファイルを探すディレクトリのリストにディレクトリ@var{dir}を加
える。

@item --output=@var{file}
出力を@file{aclocal.m4}ではなく@var{file}に置かせる。

@item --print-ac-dir
@code{aclocal}が@samp{m4}ファイルを見付けるために検索するディレクトリの
名前を出力する。このオプションが与えられると、通常の処理は抑制される。こ
のオプションはマクロ・ファイルをどこにインストールするかを決めるために、
パッケージによって使用されてもよい。

@item --verbose
調べるファイルの名前を出力する。

@item --version
Automakeのバージョン・ナンバーを出力し終了する。
@end table


@node Macros, Extending aclocal, Invoking aclocal, configure
@section Automakeと共に与えられるAutoconfのマクロ

@c consider generating this node automatically from m4 files.

@table @code
@item AM_CONFIG_HEADER
Automakeは設定ヘッダを自動的に再生成するための規則を生成するだろう。もし
このマクロを使うなら、あなたのソース・ディレクトリにファイル
@file{stamp-h.in}を作成しなければならない。それは空で良い。
@cvindex AM_CONFIG_HEADER

@item AM_CYGWIN32
この@code{configure}が@samp{Cygwin32}環境で走らされているのかどうかを調
べるために点検する。(FIXME xref)。もしそうなら、出力変数@code{EXEEXT}を
@samp{.exe}に定義する。そうでなければ、それを空文字列に定義する。
Automakeはこのマクロを認識し、@samp{Cygwin32}の下で自動的に働く
@file{Makefile.in}を生成するためにそれを使用する。@samp{Cygwin32}環境で
は、たとえコマンドラインで指定されなかったとしても、@code{gcc}は
@samp{.exe}で名前が終わる実行形式を生成する。Automakeはこれを優雅に処理
するために@file{Makefile.in}に特別なコードを加える。

@item AM_FUNC_STRTOD
もし@code{strtod}関数が利用できないか、(SunOS 5.4のもののように)上手く働
かないなら、@file{strtod.o}を出力変数@code{LIBOBJS}に加える。
@cvindex AM_FUNC_STRTOD

@item AM_FUNC_ERROR_AT_LINE
もし関数@code{error_at_line}が見付からなければ、@file{error.o}を
@code{LIBOBJS}に加える。
@cvindex AM_FUNC_ERROR_AT_LINE

@item AM_FUNC_MKTIME
実用的な@code{mktime}関数を点検する。もし見付からなければ、
@file{mktime.o}を@samp{LIBOBJS}に加える。
@cvindex AM_FUNC_MKTIME

@item AM_FUNC_OBSTACK
GNU obstackのコードを点検する。もし見付からなければ、@file{obstack.o}を
@samp{LIBOBJS}に加える。
@cvindex AM_FUNC_OBSTACK

@item AM_C_PROTOTYPES
関数プロトタイプがコンパイラによって理解されるかどうかを調べるために点検
する。もしそうなら、@samp{PROTOTYPES}を定義し、出力変数@samp{U}と
@samp{ANSI2KNR}を空文字列に設定する。そうでなければ、@samp{U}を@samp{_}
に設定し、@samp{ANSI2KNR}を@samp{./ansi2knr}に設定する。Automakeは自動的
な脱ANSI化を実装するためにこれらの値を使用する。
@cvindex AM_C_PROTOTYPES

@item AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL
もし@code{TIOCGWINSZ}の使用に@file{<sys/ioctl.h>}が必要なら、
@code{GWINSZ_IN_SYS_IOCTL}を定義する。そうでなければ、@code{TIOCGWINSZ}
は@file{<termios.h>}で見付かる。
@cvindex AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL

@item AM_INIT_AUTOMAKE
ほとんどの@file{configure.in}が必要とする多くのマクロを走らせる。このマ
クロは二つの必要な引数、パッケージとバージョン・ナンバーを持つ。デフォル
トでこのマクロは@samp{PACKAGE}と@samp{VERSION}を@code{AC_DEFINE}する。こ
れは空でない三番目の引数を渡すことで避けられる。

@item AM_PATH_LISPDIR
プログラム@code{emacs}を検索し、もしあれば、出力変数@code{lispdir}を
Emacsのsite-lispディレクトリへの完全なパスに設定する。
@cvindex AM_PATH_LISPDIR

@item AM_PROG_CC_STDC
もしCコンパイラがデフォルトでANSI Cモードでないなら、そうするように出力
変数@code{CC}にオプションを付けようとする。このマクロはあるシステムで
ANSI Cを選択し、他ではそうでない、さまざまなオプションを試す。関数プロト
タイプを正しく処理すれば、そのコンパイラがANSI Cモードであると考える。

もしこのマクロを使うなら、それを呼んだ後にCコンパイラがANSI Cを受け入れ
ると設定されているかどうか点検すべきだ。もし駄目なら、シェル変数
@code{am_cv_prog_cc_stdc}は@samp{no}に設定される。もしあなたのソース・コー
ドをANSI Cで書いたなら、@code{ansi2knr}オプションを使ってそれの脱ANSI化
されたコピーを作ることができる。
@cvindex AM_PROG_CC_STDC

@item AM_PROG_INSTALL
@code{AC_PROG_INSTALL}に似ているが、@code{INSTALL_SCRIPT}も定義する。
@cvindex AM_PROG_INSTALL

@item AM_PROG_LEX
@code{AC_DECL_YYTEXT}付きの@code{AC_PROG_LEX}に似ているが、lexを持たない
システムで@code{missing}スクリプトを使用する。@samp{HP-UX 10}はそのよう
なシステムの一つだ。
@cvindex AM_PROG_LEX

@item AM_SANITY_CHECK
これは構築ディレクトリで作られたファイルがソース・ディレクトリのファイル
より新しいことを確認するために点検する。これはクロックが間違えて設定され
ているシステムで失敗し得る。このマクロは@code{AM_INIT_AUTOMAKE}から自動
的に走らされる。
@cvindex AM_SANITY_CHECK

@item AM_SYS_POSIX_TERMIOS
POSIX termiosヘッダや関数がそのシステムで利用できるかどうかを調べるため
に点検する。もしそうなら、シェル変数@code{am_cv_sys_posix_termios}を
@samp{yes}に設定する。そうでないなら、その変数を@samp{no}に設定する。
@cvindex AM_SYS_POSIX_TERMIOS

@item AM_TYPE_PTRDIFF_T
型@samp{ptrdiff_t}が@file{<stddef.h>}で定義されていれば
@samp{HAVE_PTRDIFF_T}を定義する。
@cvindex AM_TYPE_PTRDIFF_T

@item AM_WITH_DMALLOC
@code{dmalloc}パッケージのサポートを加える。もしそのユーザが
@samp{--with-dmalloc}付きで設定すれば、@code{WITH_DMALLOC}を定義し、
@code{LIBS}に@samp{-ldmalloc}を追加する。@code{dmalloc}パッケージは
@url{ftp://ftp.letters.com/src/dmalloc/dmalloc.tar.gz}で見付けられる。
@cvindex AM_WITH_DMALLOC

@item AM_WITH_REGEX
@code{configure}コマンドラインに@samp{--with-regex}を加える。もし指定さ
れれば(デフォルト)、@samp{regex}正規表現ライブラリが使われ、
@file{regex.o}が@samp{LIBOBJS}に入れられ、@samp{WITH_REGEX}が定義される。
もし@samp{--without-regex}が与えられれば、@samp{rx}正規表現ライブラリが
使われ、@file{rx.o}が@samp{LIBOBJS}に入れられる。
@cvindex AM_WITH_REGEX
@end table


@node Extending aclocal,  , Macros, configure
@section あなた自身のaclocalマクロの記述

Aclocalはどのマクロに関しても組み込みの知識を持っていないので、あなた自
身のマクロで拡張するのは簡単だ。

これは主に他のプログラムに使われる、自分自身のAutoconfマクロを与えたいラ
イブラリで使用される。例えば、@code{gettext}ライブラリは@code{gettext}を
使用するパッケージによって使われるべきであるマクロ@code{AM_GNU_GETTEXT}
を与えている。そのライブラリがインストールされるとき、@code{aclocal}がそ
れを見付けられるようにこのマクロをインストールする。

マクロのファイルは一連の@code{AC_DEFUN}であるべきだ。Aclocalはまた
@code{AC_REQUIRE}を理解するので、別々のファイルにそれぞれのマクロを置い
ても大丈夫だ。

マクロのファイル名は@samp{.m4}で終端するべきだ。そのようなファイルは
@file{$(datadir)/aclocal}にインストールされるべきだ。

@node Top level, Programs, configure, Top
@chapter 一番上のMakefile.am

flatでないパッケージでは、一番上の階層の@file{Makefile.am}はAutomakeにど
のサブディレクトリが構築される予定なのかを教えなければならない。これは
@code{SUBDIRS}変数を使って行われる。
@vindex SUBDIRS

@code{SUBDIRS}マクロはさまざまな種類の構築が起こるサブディレクトリのリス
トを保持する。生成された@file{Makefile}の多くのターゲット(例えば
@code{all})は局所的に、そして指定された全てのサブディレクトリとで走るだろう。
@code{SUBDIRS}で列挙されるディレクトリは@file{Makefile.am}を含む必要はな
いことに注意せよ。(設定の後に)@file{Makefile}だけが必要だ。これで
(@code{gettext}のような)Automakeを使わないパッケージからライブラリを含め
ることができる。@code{SUBDIRS}で記述されるディレクトリは現在のディレクト
リの直接の子供でなければならない。例えば、@samp{src/subdir}を
@code{SUBDIRS}に入れることはできない。

deepパッケージでは、一番上層の@file{Makefile.am}はよく非常に短い。例えば、
Hello配布物の@file{Makefile.am}はこうである。

@example
EXTRA_DIST = BUGS ChangeLog.O README-alpha
SUBDIRS = doc intl po src tests
@end example

GNU @code{Inetutils}の場合のように、パッケージ全体の一部だけを構築したい
なら、@code{SUBDIRS}変数を上書きすることが可能だ。あなたの
@file{Makefile.am}では以下を含む。

@example
SUBDIRS = @@SUBDIRS@@
@end example

そしてあなたの@file{configure.in}でこう指定できる。

@example
SUBDIRS = "src doc lib po"
AC_SUBST(SUBDIRS)
@end example

これの要点は、automakeはそのパッケージをそのサブディレクトリを持つように
構築するとだまされるが、実際には@code{configure}が走らされるまでこのリス
トは固定されないということだ。


@code{SUBDIRS}はconfigureの置き換え(例えば@samp{@@DIRS@@})を含むことがで
きる。Automake自身は実際にはこの変数の中身を調べない。

もし@code{SUBDIRS}が定義されれば、あなたの@file{configure.in}は
@code{AC_PROG_MAKE_SET}を含まなければならない。

@code{SUBDIRS}の使用は一番上層の@file{Makefile.am}だけに制限されていない。
Automakeは任意の深さのパッケージを構成するように使用できる。


@node Programs, Other objects, Top level, Top
@chapter プログラムやライブラリの構築

Automakeの機能の大部分はCのプログラムやライブラリを構築するのを容易にす
ることを目的にしている。


@menu
* A Program::                   プログラムの構築
* A Library::                   ライブラリの構築
* LIBOBJS::                     LIBOBJSとALLOCAの特殊処理
* A Shared Library::            Libtoolライブラリの構築
* Program variables::           プログラムを構築するときに使用される変数
* Yacc and Lex::                YaccとLexのサポート
* C++::                         C++や他の言語
* ANSI::                        自動的な脱ANSI化
* Dependencies::                自動的な依存関係の追跡
@end menu


@node A Program, A Library, Programs, Programs
@section プログラムの構築

(ライブラリに対比して)プログラムに組み込まれるソースを含むディレクトリで
は、@samp{PROGRAMS}主要変数が使われる。プログラムは@samp{bindir}、
@samp{sbindir}、@samp{libexecdir}、@samp{pkglibdir}にインストールされる
か、全くインストールされない(@samp{noinst})。

例えば、

@example
bin_PROGRAMS = hello
@end example

この単純な場合には、結果として生じる@file{Makefile.in}は@code{hello}と名
付けられたプログラムを生成するコードを含むだろう。変数
@code{hello_SOURCES}はどのソース・ファイルが実行形式に組み込まれるかを指
定するのに使われる。

@example
hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h 
@end example

これにより記述された@samp{.c}ファイルがそれぞれ対応する@samp{.o}にコンパ
イルされる。そして全て@file{hello}を生成するためにリンクされる。

もし@samp{prog_SOURCES}が必要とされるが、指定されないなら、単一のファイ
ル@file{prog.c}がデフォルトになる。上の例では、@code{hello_SOURCES}の定
義は実際には冗長である@footnote{訳注: なんで？ デフォルトの
@file{hello.c}だけだと不足になるのではないのか？}。
@vindex _SOURCES
@vindex SOURCES

複数のプログラムが単一ディレクトリで構築され得る。複数のプログラムは単一
のソース・ファイルを共有できる。ソース・ファイルはそれぞれの
@samp{_SOURCES}定義で列挙されねばならない。

@samp{_SOURCES}定義で列挙されるヘッダ・ファイルは配布物に含まれるが、さ
もなければ無視されるだろう。それが明らかでない場合には、@samp{_SOURCES}
変数に@file{configure}で生成されるヘッダ・ファイルを含むべきではない。こ
のファイルは配布されるべきではない。Lex(@samp{.l})やyacc(@samp{.y})ファ
イルもまた列挙されて良い。@ref{Yacc and Lex}を見よ。

Automakeはプログラムにもしかすると入るかもしれないソース・ファイルを全て
知る必要がある、たとえあらゆる環境で全てのファイルが構築されるわけではな
いとしても。条件付きでのみ構築されるファイルは適切な@samp{EXTRA_}変数に
列挙されるべきだ。例えば、もし@file{hello-linux.c}が@code{hello}に条件付
きで含まれるなら、@file{Makefile.am}はこれを含む。

@example
EXTRA_hello_SOURCES = hello-linux.c
@end example

同様に、ときどき設定時に構築される予定のプログラムを決定することが役に立
つ。例えば、GNU @code{cpio}は特別な環境でのみ@code{mt}と@code{rmt}を構築
する。

この場合、@code{automake}に、構築されるかもしれないが、同時に、生成され
た@file{Makefile.in}に@code{configure}によって指定されたプログラムを使う
ようにさせるかもしれない全てのプログラムを知らせなければならない。これは
@code{configure}に@samp{_PROGRAMS}定義の値をそれぞれ置き換えさせることに
よって行われるが、付加的に構築されるプログラムを@code{EXTRA_PROGRAMS}に
列挙する。
@vindex EXTRA_PROGRAMS

もし@code{configure}で見付けられないライブラリに対してリンクする必要があ
るなら、そうするために@code{LDADD}を使うことができる。この変数は実際には
リンカのコマンドラインにいかなるオプションでも追加するのに使用できる。
@vindex LDADD

ときどき、複数のプログラムは一つのディレクトリで構築されるがリンク時に必
要なものが同じではない。この場合、@samp{@var{prog}_LDADD}変数(@var{prog}
はある@samp{_PROGRAMS}変数で現れるようなプログラムの名前であり、普通小文
字で書かれる)を広域的な@code{LDADD}を上書きするために使用できる。(もしこ
の変数が任意のプログラムに対して存在したら、このプログラムは@code{LDADD}
を使ってはリンクされない。)
@vindex _LDADD

例えば、GNU cpioでは、@code{pax}、@code{cpio}、そして@code{mt}はライブラ
リ@file{libcpio.a}に対してリンクされる。しかし、@code{rmt}は同じディレク
トリで構築され、そのようなリンクの必要性はない。また、@code{mt}と
@code{rmt}は特定のアーキテクチャでしか構築されない。ここでcpioの
@file{src/Makefile.am}がどんな風か(要約して)示す。

@example
bin_PROGRAMS = cpio pax @@MT@@
libexec_PROGRAMS = @@RMT@@
EXTRA_PROGRAMS = mt rmt

LDADD = ../lib/libcpio.a @@INTLLIBS@@
rmt_LDADD =

cpio_SOURCES = @dots{}
pax_SOURCES = @dots{}
mt_SOURCES = @dots{}
rmt_SOURCES = @dots{}
@end example

@samp{prog_LDADD}は(@samp{-l}や@samp{-L}を除き)プログラム特異的なリンカ・
フラグを渡すには不適切である。だから、この目的には@samp{prog_LDFLAGS}を
使用する。
@vindex _LDFLAGS

プログラムを実際にはこのプログラムの一部ではない他のターゲットに依存させ
るのもときには有用である。これは@samp{prog_DEPENDENCIES}変数を使って行わ
れ得る。各プログラムはそのような変数の中身に依存するが、さらに解釈が行わ
れることはない。

もし@samp{prog_DEPENDENCIES}が与えられないなら、Automakeによって計算され
る。自動的に指定される値は、@samp{prog_LDADD}の中身からほとんどの設定に
よる置換、@samp{-l}や@samp{-L}オプションが除かれたものである。残される設
定による置換は@samp{@@LIBOBJS@@}と@samp{@@ALLOCA@@}だけである。これらは
@samp{prog_DEPENDENCIES}に対し無効な値を生成させないことが分かっているの
で残される。


@node A Library, LIBOBJS, A Program, Programs
@section ライブラリの構築

ライブラリの構築はプログラムの構築に非常に似ている。この場合には、主要変
数の名前は@samp{LIBRARIES}である。ライブラリは@code{libdir}や
@code{pkglibdir}にインストールされ得る。

Libtoolと@samp{LTLIBRARIES}主要変数を使って共有ライブラリを構築する方法
に関する情報は、@xref{A Shared Library}を。

各@samp{_LIBRARIES}変数は構築されるライブラリのリストである。例えば
@file{libcpio.a}と名付けられたライブラリを作成するが、それをインストール
しないためには、こう書く。

@example
noinst_LIBRARIES = libcpio.a
@end example

ライブラリに入るソースはプログラムに対するのと全く同様に、
@samp{_SOURCES}変数によって決定される。ライブラリ名は正規化
(@pxref{Canonicalization})されるので、@file{liblob.a}に対応する
@samp{_SOURCES}変数は@samp{liblob_a_SOURCES}であって、
@samp{liblob.a_SOURCES}ではないことに注意せよ。

余分のオブジェクトは@samp{library_LIBADD}変数を使ってライブラリに追加で
きる。これは@code{configure}によって決定されるオブジェクトに使用されるべ
きだ。再びcpioから。
@vindex _LIBADD
@vindex LIBADD

@example
libcpio_a_LIBADD = @@LIBOBJS@@ @@ALLOCA@@
@end example

@node LIBOBJS, A Shared Library, A Library, Programs
@section LIBOBJSとALLOCAの特殊処理

Automakeは@code{@@LIBOBJS@@}と@code{@@ALLOCA@@}の使用を明示的に認識し、
この情報に配布物(@pxref{Dist})の適切なソース・ファイルを自動的に含めるた
めに@file{configure.in}から得た@code{LIBOBJS}ファイルのリストを加えて利
用する。これらのソース・ファイルはまた依存関係追跡の仕組みで自動的に処理
される。@xref{Dependencies}を見よ。

@code{@@LIBOBJS@@}と@code{@@ALLOCA@@}はどの@samp{_LDADD}や@samp{_LIBADD}
変数でも特別に認識される。

@node A Shared Library, Program variables, LIBOBJS, Programs
@section 共有ライブラリの構築

共有ライブラリの構築は比較的複雑な問題である。この理由のために、GNU
Libtool (@pxref{Top, , The Libtool Manual, libtool, The Libtool Manual})
がプラットフォーム独立な方法で共有ライブラリを構築するのを助けるために作
成された。

Automakeは@samp{LTLIBRARIES}主要変数で宣言されたライブラリを構築するため
にLibtoolを利用する。各@samp{_LTLIBRARIES}変数は構築する共有ライブラリの
リストである。例えば、@file{libgettext.a}と名付けられたライブラリとそれ
の対応する共有ライブラリを作成し、それらを@samp{libdir}にインストールす
るために、こう書く。

@example
lib_LTLIBRARIES = libgettext.la
@end example

共有ライブラリはインストールされ@emph{なければならない}ので、
@samp{noinst_LTLIBRARIES}と@samp{check_LTLIBRARIES}は許されない。

それぞれのライブラリに対して、@samp{library_LIBADD}変数は共有ライブラリ
に追加するために追加のlibtoolオブジェクト(@samp{.lo}ファイル)の名前を含
む。@samp{library_LDFLAGS}変数は@samp{-version-info}や@samp{-static}のよ
うな、追加のlibtoolフラグを含む。

通常のライブラリが@code{@@LIBOBJS@@}を含むようなところでは、libtoolライ
ブラリは@code{@@LTLIBOBJS@@}を使用しなければならない。これはlibtoolが扱
うオブジェクト・ファイルは必ずしも@samp{.o}で終わらないので必要である。
libtoolのマニュアルではこの話題についてもっと詳細な事を記している。

あるディレクトリにインストールされるライブラリに対して、@code{automake}
は自動的に適切な@samp{-rpath}オプションを与えるだろう。しかしながら、設
定時に決定される(したがって@code{EXTRA_LTLIBRARIES}で記述される)ライブラ
リに対しては、@code{automake}は結果になるインストール用のディレクトリが
分からない。そのようなライブラリには手で@samp{-rpath}オプションを適切な
@samp{_LDFLAGS}変数に加えなければならない。

@xref{Using Automake, Using Automake with Libtool, The Libtool Manual,
libtool, The Libtool Manual}にもっと情報がある。

@node Program variables, Yacc and Lex, A Shared Library, Programs
@section プログラムを構築するときに使用される変数

ときおりAutomakeがコンパイルに使用する@file{Makefile}変数がどれか知って
おくと便利である。例えば、ある特別な場合にはあなた自身のコンパイル作業を
行う必要があるだろう。

いくつかの変数はAutoconfから引き継がれる。これらは@code{CC}、
@code{CFLAGS}、@code{CPPFLAGS}、@code{DEFS}、@code{LDFLAGS}、そして
@code{LIBS}である。
@vindex LDFLAGS

Automake自身が定義するいくつかの追加された変数がある。

@table @code
@item INCLUDES
@samp{-I}オプションのリスト。もしあなたが参照したい特別なディレクトリが
あるなら、あなたの@file{Makefile.am}にこれを設定できる。@code{automake}
はいくつかの@samp{-I}オプションをすでに自動的に与えている。特に
@samp{-I$(srcdir)}と@file{config.h}を持つディレクトリを指す@samp{-I}を生
成する(@code{AC_CONFIG_HEADER}か@code{AM_CONFIG_HEADER}を使っているなら)。

@code{INCLUDES}は実際には@samp{-I}のほかに他の@code{cpp}オプションのため
に使用できる。例えば、ときどきコンパイラに任意の@samp{-D}オプションを渡
すために使用される。

@item COMPILE
これは実際にCのソース・ファイルをコンパイルするために使われるコマンドで
ある。ファイル名が完全なコマンドラインにするために付け加えられる。

@item LINK
これは実際にCプログラムをリンクするために使われるコマンドである。
@end table


@node Yacc and Lex, C++, Program variables, Programs
@section YaccとLexのサポート

AutomakeはYaccとLexに対していくぶん特異なサポートを有している。

Automakeはyacc(あるいはlex)によって生成された@samp{.c}ファイルは入力ファ
イルの基部名(basename)を使って名前が付けられるべきだとみなしている。すな
わち、yaccのソース・ファイル@file{foo.y}に対して、automakeは中間ファイル
を(もっと伝統的である、@file{y.tab.c}に対比して)@file{foo.c}という名前に
するだろう。

yaccソース・ファイルの拡張子は結果の@samp{C}や@samp{C++}ファイルの拡張子
を決定するのに使われる。拡張子@samp{.y}の付いたファイルは@samp{.c}ファイ
ルになるだろう。さらに、@samp{.yy}は@samp{.cc}になるだろう。@samp{.y++}
は@samp{.c++}に、そして@samp{.yxx}は@samp{.cxx}に。同様に、lexソース・ファ
イルは@samp{C}や@samp{C++}を生成するために使われる。拡張子@samp{.l}、
@samp{.ll}、@samp{.l++}、そして@samp{.lxx}が認識される。

どの@samp{SOURCES}変数でも中間の(@samp{C}や@samp{C++})ファイルを決して明
示的に記述するべきではない。ソース・ファイルだけを列挙しなさい。

yacc(あるいはlex)によって生成された中間ファイルは作られるどの配布物にも
含まれるだろう。こうしてユーザはyaccやlexを持っている必要がないのである。

もしyaccのソース・ファイルが現れるなら、あなたの@file{configure.in}は変
数@samp{YACC}を定義しなければならない。これはマクロ@samp{AC_PROG_YACC}を
起動することにより最も簡単に行われる。

同じく、もしlexのソース・ファイルが現れるなら、あなたの
@file{configure.in}は変数@samp{LEX}を定義しなければならない。これを行う
ために@samp{AC_PROG_LEX}を使用できる。Automakeのlexサポートはまた
@samp{AC_DECL_YYTEXT}マクロを使用することを必要とする---automakeは
@samp{LEX_OUTPUT_ROOT}の値を知る必要がある。

Automakeは単一のプログラムで複数のyacc(あるいはlex)のソース・ファイルを
含むことができるようにする。Automakeはサブディレクトリで@code{yacc}(ある
いは@code{lex})を走らせるために@code{ylwrap}と呼ばれる小さなプログラムを
使用する。これはyaccの出力ファイル名が固定であり、並列makeは@code{yacc}
を一つ以上同時に起動することが考えられるので必要である。@code{ylwrap}は
automakeと共に配布されている。それは@samp{AC_CONFIG_AUX_DIR}で指定される
ディレクトリか、もしこのマクロが@file{configure.in}で使用されないなら現
在のディレクトリにあるべきだ。

@code{yacc}に対して、単純に管理するロックは不十分である。@code{yacc}の出
力はまた常に内部的に同じシンボル名を使用するので、同じ実行形式に二つの
@code{yacc}パーザをリンクすることは可能ではない。

我々は@code{gdb}で使用されている以下の改名技法を使用することを推奨する。
@example
#define	yymaxdepth c_maxdepth
#define	yyparse	c_parse
#define	yylex	c_lex
#define	yyerror	c_error
#define	yylval	c_lval
#define	yychar	c_char
#define	yydebug	c_debug
#define	yypact	c_pact	
#define	yyr1	c_r1			
#define	yyr2	c_r2			
#define	yydef	c_def		
#define	yychk	c_chk		
#define	yypgo	c_pgo		
#define	yyact	c_act		
#define	yyexca	c_exca
#define yyerrflag c_errflag
#define yynerrs	c_nerrs
#define	yyps	c_ps
#define	yypv	c_pv
#define	yys	c_s
#define	yy_yys	c_yys
#define	yystate	c_state
#define	yytmp	c_tmp
#define	yyv	c_v
#define	yy_yyv	c_yyv
#define	yyval	c_val
#define	yylloc	c_lloc
#define yyreds	c_reds
#define yytoks	c_toks
#define yylhs	c_yylhs
#define yylen	c_yylen
#define yydefred c_yydefred
#define yydgoto	c_yydgoto
#define yysindex c_yysindex
#define yyrindex c_yyrindex
#define yygindex c_yygindex
#define yytable	 c_yytable
#define yycheck	 c_yycheck
@end example

それぞれの定義に対して、@samp{c_}接頭辞をあなたの好きなどんなものにでも
置き換えなさい。これらの定義は@code{bison}、@code{byacc}や伝統的な
@code{yacc}で動作する。もしここで含まれていないシンボルを使用するパーザ・
ジェネレータ(parser generator)を見付けたら、リストに加えられるように新し
い名前を報告してください。


@node C++, ANSI, Yacc and Lex, Programs
@section C++や他の言語

AutomakeはC++に対する完全なサポートと、他の言語に対する発展途上なサポー
トを含んでいる。他の言語に対するサポートは要求に応じて改良されるだろう。

C++コードを含むパッケージは出力変数@samp{CXX}を@file{configure.in}で定義
しなければならない。これを行う一番簡単な方法は@code{AC_PROG_CXX}マクロを
使用することである。

C++のソース・ファイルが現れるとき、少数の変数が追加されて定義される。

@table @code
@item CXX
C++コンパイラの名前。
@vindex CXX

@item CXXFLAGS
C++コンパイラに渡すフラグ。
@vindex CXXFLAGS

@item CXXCOMPILE
C++のソース・ファイルを実際にコンパイルするために使われるコマンド。ファ
イル名が完全なコマンドラインにするために付け加えられる。
@vindex CXXCOMPILE

@item CXXLINK
C++プログラムを実際にリンクするために使われるコマンド。
@vindex CXXLINK
@end table


@node ANSI, Dependencies, C++, Programs
@section 自動的な脱ANSI化

GNU標準はANSI Cの使用を許しているが、これはいくつかの古いコンパイラ(特に
SunOS)へのパッケージの移植性を制限するという影響を持つ。

Automakeは実際のコンパイルが行われる前にそれぞれのソース・ファイルを``脱
ANSI化''することによって、そのようなマシンに関する問題を解決できる。

もし@file{Makefile.am}の変数@code{AUTOMAKE_OPTIONS}
@vindex AUTOMAKE_OPTIONS
(@ref{Options})がオプション@code{ansi2knr}
@opindex ansi2knr
を含めば、脱ANSI化を処理するコードが生成される@file{Makefile.in}に挿入さ
れる。

これでそのディレクトリのそれぞれのCのソース・ファイルがANSI Cとして扱わ
れる。もしANSI Cコンパイラが利用可能なら、それが使われる。もしANSI Cコン
パイラが利用できないなら、ソース・ファイルをK&Rに変換するために
@code{ansi2knr}プログラムが使用され、それが次にコンパイルされる。

@code{ansi2knr}プログラムは単純である。ソース・コードが特定の方法で構成
されるとみなす。詳細は@code{ansi2knr}のmanページを見よ。

脱ANSI化のサポートにはANSI Cのソースと同じパッケージにソース・ファイル
@file{ansi2knr.c}と@file{ansi2knr.1}があることが必要である。これらのファ
イルはAutomakeと一緒に配布されている。また、そのパッケージの
@file{configure.in}はマクロ@code{AM_C_PROTOTYPES}を呼び出さなければなら
ない。
@cvindex AM_C_PROTOTYPES

Automakeはまた現在のパッケージの他のあるディレクトリで@code{ansi2knr}サ
ポート・ファイルを見付ける処理を行う。これは適切なディレクトリへの相対パ
スを@code{ansi2knr}オプションの前に付けることで行われる。例えば、パッケー
ジが@file{src}と@file{lib}サブディレクトリにANSI Cコードを持っていると考
えなさい。ファイル@file{ansi2knr.c}と@file{ansi2knr.1}は@file{lib}にある。
すると@file{src/Makefile.am}ではこのようになるだろう。

@example
AUTOMAKE_OPTIONS = ../lib/ansi2knr
@end example

もしディレクトリの接頭辞が与えられないなら、ファイルは現在のディレクトリ
にあるとみなされる。

@node Dependencies,  , ANSI, Programs
@section 自動的な依存関係の追跡

開発者としては、インクルード・ファイルの依存関係があるプロジェクトで変更
する度に継続的に@file{Makefile.in}を更新するのはしばしば骨が折れる。
@code{automake}は自動的に依存関係の変更を追跡し、生成される
@file{Makefile.in}で依存関係を配布する方法を提供する。

現在このサポートはGNU @code{make}と@code{gcc}の使用を必要とする。もし十
分な要求があれば、異なる依存関係生成プログラムを与えることが将来可能にな
るかもしれない。一方、このモードはもしCプログラムやライブラリが現在のディ
レクトリで定義されていればデフォルトで有効にされるので、GNU以外のmakeか
らは@samp{Must be a separator}エラーを受け取るかもしれない。

配布物を作ることに決めるとき、@code{dist}
@trindex dist
ターゲットは@code{automake}に@samp{--include-deps}や他のオプションを付け
て再び走らせる。これによりその前に生成された依存関係が生成される
@file{Makefile.in}に挿入され、このようにして配布物に入れられる。この段階
はまた、あなたの配布物をダウンロードするがGNU @code{make}や@code{gcc}を
使わない人々がエラーを受け取らないように、依存関係生成コードの挿入を起こ
さないようにする。

@file{Makefile.in}に加えるとき、その依存関係から全てのシステム特異的な依
存関係が取り除かれる。これは@samp{OMIT_DEPENDENCIES}でファイルを列挙する
ことで行われる。
@vindex OMIT_DEPENDENCIES
例えば、システムのヘッダ・ファイルへの全ての参照が@code{automake}によっ
て取り除かれる。ときどき特定のヘッダ・ファイルが取り除かれるように指定す
ることが役に立つ。例えば、もしあなたの@file{configure.in}が
@samp{AM_WITH_REGEX}を使用するなら、ユーザがパッケージを設定するまで正し
いものが分からないので、@file{rx.h}や@file{regex.h}に関する依存関係は取
り除かれるべきである。

分かるだろうが、@code{automake}は正規表現のヘッダという特別な場合を扱う
には実際十分利口である。またもし@samp{AM_GNU_GETTEXT}が使われれば、自動
的に@file{libintl.h}を省く。

自動的な依存関係追跡は@code{no-dependencies}を変数
@code{AUTOMAKE_OPTIONS}に入れることで抑えられる。
@vindex AUTOMAKE_OPTIONS
@opindex no-dependencies

もし@code{make dist}によって作られた配布物を展開して、依存関係追跡コード
を再び有効にしたいなら、単に@code{automake}を再び走らせなさい。

実際の依存関係ファイルは構築ディレクトリの下に、@file{.deps}と名付けられ
たサブディレクトリの中に置かれる。これらの依存関係はマシンに特異的である。
そうしたいならそれらを削除するのが安全である。それらは次の構築の間に自動
的に再作成されるだろう。


@node Other objects, Other GNU Tools, Programs, Top
@chapter 他の派生したオブジェクト

AutomakeはCプログラムではない派生したオブジェクトを扱うことができる。と
きどき実際にそのようなオブジェクトを構築するためのサポートが明示的に提供
されていなければならないが、Automakeはそれでもなお自動的にインストールや
配布を処理するだろう。

@menu
* Scripts::                     実行可能なスクリプト
* Headers::                     ヘッダ・ファイル
* Data::                        アーキテクチャ独立なデータ・ファイル
* Sources::                     派生したソース
@end menu


@node Scripts, Headers, Other objects, Other objects
@section 実行可能なスクリプト

スクリプトであるプログラムを定義しインストールすることが可能である。その
ようなプログラムは@samp{SCRIPTS}主要名を使って列挙される。
@code{automake}はスクリプトには依存関係を定義しない。@file{Makefile.am}
は適切な規則を含むべきだ。
@vindex SCRIPTS

@code{automake}はスクリプトは派生したオブジェクトであるとはみなさない。
そのようなオブジェクトは手で削除されねばならない。より多くの情報を求める
には@ref{Clean}を見よ。

@code{automake}それ自体は@file{automake.in}から設定時に生成されるスクリ
プトである。ここにこれがどう扱われているかを見せる。

@example
bin_SCRIPTS = automake
@end example

@code{automake}は@code{AC_OUTPUT}マクロに現れるので、それのためのターゲッ
トは自動的に生成される。

スクリプト・オブジェクトは@code{bindir}、@code{sbindir}、
@code{libexecdir}、あるいは@code{pkgdatadir}にインストールされ得る。


@node Headers, Data, Scripts, Other objects
@section ヘッダ・ファイル

ヘッダ・ファイルは@samp{HEADERS}系の変数によって指定される。一般的にはヘッ
ダ・ファイルはインストールされないので、@code{noinst_HEADERS}変数が一番
使用されるだろう。
@vindex HEADERS

全てのヘッダ・ファイルはどこかに列挙されていなければならない。抜かしてい
るものは配布物には現れないだろう。しばしばインストールされないヘッダをプ
ログラムの残りのソースと共に列挙することが最もすっきりしている。@xref{A
Program}。@samp{_SOURCES}変数に列挙されるヘッダは@samp{_HEADERS}変数に列
挙される必要がない。

ヘッダは@code{includedir}、@code{oldincludedir}、あるいは
@code{pkgincludedir}にインストールされ得る。


@node Data, Sources, Headers, Other objects
@section アーキテクチャ独立なデータ・ファイル

Automakeは@samp{DATA}系の変数を使って雑多なデータ・ファイルのインストー
ル作業をサポートする。
@vindex DATA

そのようなデータはディレクトリ@code{datadir}、@code{sysconfdir}、
@code{sharedstatedir}、@code{localstatedir}、あるいは@code{pkgdatadir}に
インストールされ得る。

デフォルトで、データ・ファイルは配布物に含まれない。

ここに@code{automake}がその補助データ・ファイルをインストールする方法を
示す。

@example
pkgdata_DATA = clean-kr.am clean.am @dots{}
@end example


@node Sources,  , Data, Other objects
@section 構築されるソース

ときおりそうでなければ``ソース''と呼ばれたようなファイル(例えば、Cの
@samp{.h}ファイル)は実際にはある他のファイルから派生している。そのような
ファイルは@code{BUILD_SOURCES}変数に列挙されるべきだ。
@vindex BUILT_SOURCES

構築されるソースはまたデフォルトでコンパイルされない。これが起きるように
ある他の@samp{_SOURCES}変数でそれらを明示的に記述しなければならない。

いくつかの場合には、@code{BUILD_SOURCES}がいくぶん意外な方法で働くことに
注意しなさい。構築されるソースが自動的な依存関係追跡と働くようにするため
に、@file{Makefile}は@code{$(BUILT_SOURCES)}に依存しなければならない。こ
れによりこれらのソースが何かがおかしく見えるようなときに再構築されるよう
になる。


@node Other GNU Tools, Documentation, Other objects, Top
@chapter 他のGNUツール

Automakeは基本的にGNUプログラムで使用する@file{Makefile.in}を生成するこ
とを目論まれているので、他のGNUツールと一生懸命互換性を持とうとしている。

@menu
* Emacs Lisp::                  Emacs Lisp
* gettext::                     Gettext
* Guile::                       Guile
* Libtool::                     Libtool
* Java::                        Java
@end menu

@node Emacs Lisp, gettext, Other GNU Tools, Other GNU Tools
@section Emacs Lisp

AutomakeはEmacs Lispに対してある程度のサポートを提供している。
@samp{LISP}主要変数は@samp{.el}ファイルのリストを保持するために使われる。
この主要変数の可能な接頭辞は@samp{lisp_}と@samp{noinst_}である。もし
@code{lisp_LISP}が定義されれば、@file{configure.in}は
@code{AM_PATH_LISPDIR} (@pxref{Macros})を走らせなければならないことに注
意せよ。
@vindex LISP
@vindex lisp_LISP
@vindex noinst_LISP

デフォルトでAutomakeは@code{AM_PATH_LISPDIR}によって見付かるEmacsを使っ
て全てのEmacs Lispソース・ファイルをバイト・コンパイルするだろう。もしバ
イト・コンパイルを避けたいなら、単に変数@samp{ELCFILES}を空であると定義
しなさい。
@vindex ELCFILES
バイト・コンパイルされたEmacs LispファイルはEmacsの全てのバージョンに使
えるわけではないので、もしサイトが二つ以上のEmacsのバージョンをインストー
ルしていると考えるなら、これを無効にすることには意味がある。さらに、多く
のパッケージは実際にはバイト・コンパイルの利益を得られない。それでもなお、
我々はデフォルトでそれを有効なままにしておくことを勧める。おそらく奇妙な
設定をしているサイトが彼ら自身のために対処する方が、それ以外のみんなにとっ
てインストール作業をまずいものにしてしまうより良い。

@node gettext, Guile, Emacs Lisp, Other GNU Tools
@section Gettext

もし@code{AM_GNU_GETTEXT}が@file{configure.in}に現れれば、Automakeは国際
化のためのメッセージ・カタログ・システム、GNU gettext(@pxref{GNU
Gettext, , , gettext, GNU gettext utilities})のサポートを有効にする。

Automakeの@code{gettext}サポートにはパッケージに二つのサブディレクトリ、
@file{intl}と@file{po}を追加することが必要である。Automakeはこれらのディ
レクトリが存在し、@code{SUBDIRS}に記述されていることを保証する。

さらに、Automakeは@file{configure.in}の@samp{ALL_LINGUAS}の定義が全ての
有効な@samp{.po}ファイルに対応しており、それ以上にはないことを点検する。


@node Guile, Libtool, gettext, Other GNU Tools
@section Guile

AutomakeはGuileモジュールを書くためのいくらか自動的なサポートを提供する。
Automakeはもし@code{AM_INIT_GUILE_MODULE}マクロが@file{configure.in}に使
われていれば、Guileサポートを有効にするだろう。

ちょうど今はGuileサポートは単に@code{AM_INIT_GUILE_MODULE}マクロが以下を
表すと理解されることだけを意味している。
@itemize @bullet
@item
@code{AM_INIT_AUTOMAKE}が走らされる。

@item
@code{AC_CONFIG_AUX_DIR}が@file{..}のパス付きで走らされる。
@end itemize

Guileモジュール・コードが成熟するにつれて、Automakeのサポートも発達する
ことは疑いない。

@node Libtool, Java, Guile, Other GNU Tools
@section Libtool

Automakeは@samp{LTLIBRARIES}主要変数でGNU Libtool(@pxref{Top, , The
Libtool Manual, libtool, The Libtool Manual})のサポートを提供している。
@xref{A Shared Library}。

@node Java, , Libtool, Other GNU Tools
@section Java

Automakeは@samp{JAVA}主要変数でJavaコンパイル作業の最小限のサポートを提
供する。

@samp{_JAVA}変数に列挙されるどの@samp{.java}ファイルでも構築時に
@code{JAVAC}でコンパイルされるだろう。デフォルトで、@samp{.class}ファイ
ルは配布物には含まれない。

現在Automakeは任意の@file{Makefile.am}で一つだけの@samp{_JAVA}主要変数が
使えるという制限を課している。この制限の理由は、一般的に、どの
@samp{.class}ファイルがどの@samp{.java}ファイルから生成されたのかを知る
ことができないということである --- だからどのファイルがどこにインストー
ルされるかを知ることが不可能なのだ。


@node Documentation, Install, Other GNU Tools, Top
@chapter 解説書の構築

現在AutomakeはTexinfoやmanページのサポートを提供している。

@menu
* Texinfo::                     Texinfo
* Man pages::                   manページ
@end menu


@node Texinfo, Man pages, Documentation, Documentation
@section Texinfo

もし現在のディレクトリがTexinfoのソースを含むなら、それを@samp{TEXINFOS}
主要変数で宣言しなければならない。一般的にTexinfoファイルはinfoに変換さ
れるので、@code{info_TEXINFOS}マクロが最もありふれて使われている。
Texinfoのソース・ファイルは@samp{.texi}か@samp{.texinfo}拡張子で終端しな
ければならないことに注意せよ。
@vindex TEXINFOS
@vindex info_TEXINFOS

もし@samp{.texi}ファイルが@file{version.texi}を@code{@@include}するなら、
このファイルは自動的に生成されるだろう。@file{version.texi}は参照可能な
三つのTexinfoマクロを定義する。@code{EDITION}、@code{VERSION}、そして
@samp{UPDATED}である。最初の二つはあなたのパッケージのバージョン・ナンバー
を保持する(が明瞭なように別々にされている)。最後のは主要なファイルが最後
に変更された日付である。@file{version.texi}サポートには@code{mdata-sh}プ
ログラムが必要である。このプログラムはAutomakeと共に与えられている。

ときどきinfoファイルは実際には二つ以上の@samp{.texi}ファイルに依存してい
る。例えば、GNU Helloでは、@file{hello.texi}はファイル@file{gpl.texi}を
含む。Automakeにこれらの依存関係について@samp{@var{texi}_TEXINFOS}変数を
使って教えることができる。ここにHelloがそれをどうやっているかを示す。
@vindex TEXINFOS
@vindex _TEXINFOS

@example
info_TEXINFOS = hello.texi
hello_TEXINFOS = gpl.texi
@end example

デフォルトで、AutomakeはTexinfoのソースと同じディレクトリにファイル
@file{texinfo.tex}があることを必要とする。しかしながら、もし
@file{configure.in}で@code{AC_CONFIG_AUX_DIR}を使ったなら、
@file{texinfo.tex}はそこで探される。Automakeはもし@samp{--add-missing}が
与えられれば、@file{texinfo.tex}を与えてくれる。

もしあなたのパッケージが多くのディレクトリでTexinfoファイルを持っている
なら、automakeにあなたのパッケージの正しい@file{texinfo.tex}をどこで見付
けるかを教えるために変数@code{TEXINFO_TEX}を使用できる。この変数の値は現
在の@file{Makefile.am}から@file{texinfo.tex}への相対パスであるべきだ。

@example
TEXINFO_TEX = ../doc/texinfo.tex
@end example

オプション@samp{no-texinfo.tex}が@file{texinfo.tex}の必要性を失くすため
に使われ得る。しかしながら、@code{dvi}ターゲットがそれでも働くようにする
ので、変数@code{TEXINFO_TEX}の使用がより好ましい。

Automakeは@code{install-info}ターゲットを生成する。いくらかの人々は明ら
かにこれを使う。デフォルトでは、infoページは@samp{make install}でインス
トールされる。これは@code{no-installinfo}オプションにより妨げられる。


@node Man pages,  , Texinfo, Documentation
@section manページ

パッケージはまたmanページを含むことができる。(だけどこの件についてGNU標
準を見なさい、@ref{Man Pages, , , standards, The GNU Coding Standards}。)
manページは@samp{MANS}主要変数を使って宣言される。一般的に
@code{man_MANS}マクロが使用される。manページはファイルの拡張子に基いて、
自動的に正しい@code{mandir}のサブディレクトリにインストールされる。
@vindex MANS
@vindex man_MANS

@c Use @samp{make install} per documentation: (texi)code.
デフォルトでは、manページは@samp{make install}によってインストールされる。
しかし、GNUプロジェクトはmanページを必要としないので、多くの管理者はman
ページを最新状態にしようと努力しない。この場合には、@code{no-installman}
オプションがmanページをデフォルトでインストールされないようにするだろう。
ユーザはそれでもなお@samp{make install-man}によって明示的にそれらをイン
ストールすることができる。
@opindex no-installman
@trindex install-man

ここに解説書がGNU @code{cpio}でどう扱われるかを示す(それはTexinfo解説書
とmanページの両方を含む)。

@example
info_TEXINFOS = cpio.texi
man_MANS = cpio.1 mt.1
@end example

Texinfoのソースとinfoページは配布物を作るという目的には全てソースである
と考えられる。

manページは現在のところソースであると考えられない、なぜならmanページが自
動的に生成されるのは珍しくないからだ。


@node Install, Clean, Documentation, Top
@chapter 何がインストールされるか

もちろん、Automakeはあなたのプログラムが構築されたなら、それを実際にイン
ストールすることを詳細に扱う。@code{PROGRAMS}、@code{SCRIPTS}、
@code{LIBRARIES}、@code{LISP}、@code{DATA}と@code{HEADERS}の全てが適切な
場所に自動的にインストールされる。

Automakeはまた指定されたinfoやmanページのインストールも扱う。

Automakeはディレクトリ構造を共有する複数のマシンにそのインストーラがイン
ストールする場合には、@code{install-data}と@code{install-exec}ターゲット
を別々に生成する---これらのターゲットはマシン独立な部分がたった一度だけ
インストールされるようにする。@code{install}ターゲットはこれらのターゲッ
トの両方に依存している。
@trindex install-data
@trindex install-exec
@trindex install

Automakeはまた@code{uninstall}ターゲット、@code{installdirs}ターゲット、
そして@code{install-script}ターゲットを生成する。
@trindex uninstall
@trindex installdirs
@trindex install-strip

この機構を@code{install-exec-local}や@code{install-data-local}ターゲット
を定義することで拡張することが可能である。もしこれらのターゲットが存在す
れば、それらは@samp{make install}のときに実行されるだろう。
@trindex install-exec-local
@trindex install-data-local

標準的なディレクトリ接頭辞、@samp{data}、@samp{info}、@samp{man}、
@samp{include}、@samp{oldinclude}、@samp{pkgdata}や@samp{pkginclude}を使
う変数(例えば、@samp{data_DATA})は@samp{install-data}によってインストー
ルされる。

標準的なディレクトリ接頭辞、@samp{bin}、@samp{sbin}、@samp{libexec}、
@samp{sysconf}、@samp{localstate}、@samp{lib}や@samp{pkglib}を使う変数
(例えば、@samp{bin_PROGRAMS})は@samp{install-exec}によってインストールさ
れる。

その名前に@samp{exec}の付いたユーザ定義のディレクトリ接頭辞を使う変数(例
えば、@samp{myexecbin_PROGRAMS})は@samp{install-exec}によってインストー
ルされる。他のユーザ定義接頭辞は全て@samp{install-data}によってインストー
ルされる。

Automakeは全てのインストール規則で@samp{DESTDIR}変数に対するサポートを生
成する。@xref{Makefile Conventions, , , standards, The GNU Coding
Standards}を見よ。
@vindex DESTDIR


@node Clean, Dist, Install, Top
@chapter 何がクリーンされるか

GNU Makefile標準はたくさんの異なったクリーン規則を指定する。
@c FIXME xref
一般的にクリーンされるファイルはAutomakeによって自動的に決定される。もち
ろん、Automakeはまたクリーンされる追加ファイルを指定するために定義される
いくつかの変数を認識する。これらの変数は@code{MOSTLYCLEANFILES}、
@code{CLEANFILES}、@code{DISTCLEANFILES}、そして
@code{MAINTAINERCLEANFILES}である。
@vindex MOSTLYCLEANFILES
@vindex CLEANFILES
@vindex DISTCLEANFILES
@vindex MAINTAINERCLEANFILES


@node Dist, Tests, Clean, Top
@chapter 何が配布物に含まれるか

生成される@file{Makefile.in}の@code{dist}ターゲットは配布のためにgzipさ
れた@code{tar}ファイルを生成するために使われる。tarファイルは
@samp{PACKAGE}や@samp{VERSION}変数に基いて名付けられる。もっと正確には
@samp{@var{package}-@var{version}.tar.gz}と名付けられる。
@cvindex PACKAGE
@cvindex VERSION
@trindex dist

多くの場面では、配布するファイルはAutomakeによって自動的に見付けられる。
全てのソース・ファイルは全ての@file{Makefile.am}と@file{Makefile.in}のよ
うに配布物に自動的に入れられる。Automakeはまた、もし現在のディレクトリに
あれば自動的に含められるよく使われるファイルの組み込みのリストを持ってい
る。このリストは@samp{automake --help}で表示される。また、
@code{configure}によって読まれるファイル(すなわち、@code{AC_OUTPUT}の起
動で指定されるファイルに対応するソース・ファイル)は自動的に配布される。

それでもなお、ときどき配布されなければならないが、自動的な規則に収められ
ていないファイルがある。これらのファイルは@code{EXTRA_DIST}変数に列挙さ
れるべきだ。@code{EXTRA_DIST}は現在のディレクトリのファイルだけを扱える
ことに注意せよ。他のディレクトリのファイルだと、@code{make dist}が実行時
に失敗するだろう。
@vindex EXTRA_DIST

もし@code{SUBDIRS}を定義すれば、automakeは配布物に再帰的にサブディレクト
リを含めるだろう。もし@code{SUBDIRS}が条件付きで(@pxref{Conditionals})定
義されれば、automakeは通常配布物の@code{SUBDIRS}に現れるかもしれないディ
レクトリを全て含めるだろう。もし条件付きでディレクトリの組を指定する必要
があれば、変数@code{DIST_SUBDIRS}に配布物に含める厳密なサブディレクトリ
のリストを設定することができる。
@vindex DIST_SUBDIRS

ときおりまとめられる前に配布物を変更できると便利である。もし
@code{dist-hook}ターゲットが存在すれば、それが配布物のディレクトリが埋め
られた後だが、実際のtar(あるいはshar)ファイルが作成される前に走らされる。
これを使う一つの観点は新しい@file{Makefile.am}がやり過ぎるようなサブディ
レクトリのファイルを配布するためである。

@example
dist-hook:
        mkdir $(distdir)/random
        cp -p random/a1 random/a2 $(distdir)/random
@end example

Automakeはまた任意の配布物が実際に働くことを保証する助けになる
@code{distcheck}ターゲットを生成する。@code{distcheck}は配布物を作り、そ
して@code{VPATH}の構築を行おうとする。
@trindex distcheck
@c FIXME: document distcheck-hook here

@node Tests, Options, Dist, Top
@chapter テストのサポート

Automakeは二つの形式のテストをサポートしている。

もし変数@code{TESTS}が定義されれば、その値は試験を行うために実行するプロ
グラムのリストであると解釈される。そのプログラムは派生したオブジェクトで
もソース・オブジェクトでも良い。生成された規則は@var{srcdir}と@file{.}の
両方を見るだろう。データ・ファイルを必要とするプログラムは別ディレクトリ
で構築するとき(@pxref{Build Directories, , , , autoconf})に働くように
@var{srcdir}(それは環境変数とmake変数の両方である)でそれらを、特に
@code{distcheck}ターゲット(@pxref{Dist})のために見るべきである。

失敗の数は実行の終わりに表示されるだろう。もし任意のテスト・プログラムが
77の状態で終了すれば、その結果は最終的な計算では無視される。この特徴は移
植可能でないテストが意味をなさない環境で無視されるようにする。

変数@code{TESTS_ENVIRONMENT}はテスト実行のために環境変数を設定するために
使用できる。環境変数@code{srcdir}は規則で設定される。もしあなたのテスト・
プログラムが全てスクリプトなら、@code{TESTS_ENVIRONMENT}をシェルの起動
(例えば、@samp{$(SHELL) -x})に設定できる。これはテストのデバッグに有用で
ある。
@vindex TESTS
@vindex TESTS_ENVIRONMENT

もし@samp{dejagnu}が@code{AUTOMAKE_OPTIONS}に現れれば、@code{dejagnu}に
基くテストが想定される。変数@code{DEJATOOL}の値は@code{runtest}への
@code{--tool}引数として渡される。それはパッケージの名前がデフォルトであ
る。

変数@code{RUNTESTDEFAULTFLAGS}はデフォルトでdejagnuに渡される
@code{--tool}と@code{--srcdir}のフラグを保持する。これは必要なら上書きし
て良い。
@vindex RUNTESTDEFAULTFLAGS

変数@code{EXPECT}、@code{RUNTEST}や@code{RUNTESTFLAGS}はまたプロジェクト
に特異的な値を与えるために上書きされ得る。例えば、もしコンパイラのツール
の繋がりをテストしているなら、デフォルトの値はhostとtargetの名前を考慮に
入れていないので、これを行う必要があるだろう。
@opindex dejagnu
@vindex DEJATOOL
@vindex EXPECT
@vindex RUNTEST
@vindex RUNTESTFLAGS
@c FIXME xref dejagnu

どちらの場合でも、試験は@samp{make check}によって行われる。


@node Options, Miscellaneous, Tests, Top
@chapter Automakeの挙動の変更

Automakeのさまざまな特徴は@file{Makefile.am}のオプションによって制御され
得る。そのようなオプションは@code{AUTOMAKE_OPTIONS}という名前の特別な変
数に列挙される。現在理解されるオプションは以下である。
@vindex AUTOMAKE_OPTIONS

@table @asis
@item @code{gnits}
@itemx @code{gnu}
@itemx @code{foreign}
@item @code{cygnus}
strictnessをそのように設定する。@code{gnits}オプションはまた
@code{readme-alpha}と@code{check-news}を暗示する。

@item @code{ansi2knr}
@itemx @code{path/ansi2knr}
自動的な脱ANSI化を有効にする。@xref{ANSI}。もしパスに先行されていれば、
生成された@file{Makefile.in}は@file{ansi2knr}プログラムを見付けるのに指
定されたディレクトリで探すだろう。一般的にパスは同じ配布物の他のディレク
トリへの相対パスであるべきだ(Automakeは今のところこれを点検しないけど)。

@item @code{check-news}
@file{NEWS}ファイルの最初の数行に現在のバージョン・ナンバーが現れなけれ
ば@code{make dist}が失敗するようにする。

@item @code{dejagnu}
@code{dejagnu}特有の規則が生成されるようにする。@xref{Tests}。

@item @code{dist-shar}
通常の@code{dist}だけでなく@code{dist-shar}ターゲットも生成する。この新
しいターゲットは配布物のsharアーカイブを作成するだろう。
@trindex dist-shar

@item @code{dist-zip}
通常の@code{dist}だけでなく@code{dist-zip}ターゲットも生成する。この新し
いターゲットは配布物のzipアーカイブを作成するだろう。
@trindex dist-zip

@item @code{dist-tarZ}
通常の@code{dist}ターゲットだけでなく@code{dist-tarZ}ターゲットも生成す
る。この新しいターゲットは配布物の圧縮されたtarアーカイブを作成するだろ
う。伝統的な@code{tar}と@code{compress}であるとされるだろう。警告、もし
実際には@code{GNU tar}を使っているなら、生成されたアーカイブは移植性のな
い構成物を含むかもしれない。
@trindex dist-tarZ

@item @code{no-dependencies}
これはコマンドラインで@samp{--include-deps}を使うのに似ているが、自動的
な依存関係追跡が働くようにする(@xref{Dependencies})のに必要なわずかなも
のを持っていないような状況に有用である。この場合、その影響は事実上自動的
な依存関係追跡を無効にすることである。

@item @code{no-installinfo}
生成された@file{Makefile.in}はinfoページがデフォルトでは構築されたりイン
ストールされたりしないようにするだろう。しかし、@code{info}と
@code{install-info}ターゲットはなお利用可能であるだろう。このオプション
は@samp{GNU}のstrictnessやそれ以上では禁止されている。
@trindex info
@trindex install-info

@item @code{no-installman}
生成された@file{Makefile.in}はmanページがデフォルトでインストールされな
いようにするだろう。しかし、@code{install-man}ターゲットは付加的なインス
トール作業として利用可能であるだろう。このオプションは@samp{GNU}の
strictnessやそれ以上では禁止されている。
@trindex install-man

@item @code{no-texinfo.tex}
このディレクトリにtexinfoファイルがあっても、@file{texinfo.tex}を必要と
しない。

@item @code{readme-alpha}
もしこのリリースがalphaリリースで、ファイル@file{README-alpha}が存在すれ
ば、それが配布物に加えられるだろう。もしこのオプションが与えられれば、バー
ジョン・ナンバーは二つの形式の一つに従うと期待される。最初の形式は
@samp{@var{MAJOR}.@var{MINOR}.@var{ALPHA}}で、それぞれの要素は数字である。
最後のピリオドと数字はalphaでないリリースでは除かれるべきだ。二番目の形
式は@samp{@var{MAJOR}.@var{MINOR}@var{ALPHA}}で、@var{ALPHA}は文字である。
それはalphaでないリリースでは省かれるべきだ。

@item @var{version}
バージョン・ナンバー(例えば、@samp{0.30})が指定され得る。もしAutomakeが
指定されたバージョンよりも新しくなければ、@file{Makefile.in}の作成が抑制
されるだろう。
@end table

認識されないオプションは@code{automake}によって診断される。


@node Miscellaneous, Conditionals, Options, Top
@chapter 雑多な規則

他のところには当てはまらなかった、少数の規則や変数がある。

@menu
* Tags::                        etagsとmkidのインターフェース
* Suffixes::                    新しいファイル拡張子の扱い
@end menu


@node Tags, Suffixes, Miscellaneous, Miscellaneous
@section @code{etags}へのインターフェース

@code{automake}はいくつかの環境でGNU Emacsで使われる@file{TAGS}ファイル
を生成する規則を生成するだろう。

もしCのソース・コードやヘッダがあれば、@code{tags}と@code{TAGS}ターゲッ
トがそのディレクトリに対して生成されるだろう。
@trindex tags

複数ディレクトリのパッケージの最上位のディレクトリで、@code{tags}ターゲッ
ト・ファイルが生成され、それは実行するときにサブディレクトリから全ての
@file{TAGS}ファイルを参照によって含む@file{TAGS}ファイルを生成するだろう。

また、もし変数@code{ETAGS_ARGS}が定義されれば、@code{tags}ターゲットが生
成されるだろう。この変数は@code{etags}が理解しないタグ付けできるソースを
含むディレクトリでの使用を意図されている。
@vindex ETAGS_ARGS

ここにAutomakeがそのソースと、そのTexinfoファイルの節(node)に対するタグ
を生成する方法を示す。

@example
ETAGS_ARGS = automake.in --lang=none \
 --regex='/^@@node[ \t]+\([^,]+\)/\1/' automake.texi
@end example

もし@samp{ETAGS_ARGS}にファイル名を加えるなら、おそらく
@samp{TAGS_DEPENDENCIES}も設定したいだろう。この変数の中身は@code{tags}
ターゲットに対する依存関係に直接加えられる。
@vindex TAGS_DEPENDENCIES

Automakeはまたソースに@code{mkid}を走らせる@code{ID}ターゲットも生成する
だろう。これはディレクトリずつの原理(directory-by-directory basis)でだけ
サポートされる。
@trindex id


@node Suffixes,  , Tags, Miscellaneous
@section 新しいファイル拡張子の扱い

Automakeが知らないファイルの種類を扱うために新しい暗黙の規則を導入するこ
とがときどき役に立つ。もしこれがなされるなら、GNU Makeに新しい拡張子を知
らせねばならない。これは@code{SUFFIXES}変数に新しい拡張子のリストを付け
ることで行われ得る。
@vindex SUFFIXES

例えば、現在automakeはJavaサポートを提供していない。もし@samp{.java}ソー
ス・ファイルから@samp{.class}ファイルを生成するマクロを書いたなら、これ
らの拡張子をそのリストに加える必要もあるだろう。

@example
SUFFIXES = .java .class
@end example

@node Conditionals, Gnits, Miscellaneous, Top
@chapter 条件文

Automakeは単純な種類の条件文をサポートする。

@cvindex AM_CONDITIONAL
条件文を使う前に、@code{configure.in}ファイルで@code{AM_CONDITIONAL}を使っ
てそれを定義しなければならない。@code{AM_CONDITIONAL}マクロは二つの引数
を受け取る。

@code{AM_CONDITIONAL}への最初の引数は条件文の名前である。これは文字で始
まり、文字や整数、アンダースコアだけを含む単純な文字列であるべきだ。

@code{AM_CONDITIONAL}への二つ目の引数はシェルのif文での利用に適した、シェ
ルの条件文である。その条件文は@code{configure}が実行されるときに評価され
る。

条件文は典型的にはユーザが@code{configure}スクリプトに与えるオプションに
依存している。ここにもしユーザが@samp{--enable-debug}オプションを使えば
真である条件文の書き方の例がある。

@example
AC_ARG_ENABLE(debug,
[  --enable-debug    Turn on debugging],
[case "$@{enableval@}" in
  yes) debug=true ;;
  no)  debug=false ;;
  *) AC_MSG_ERROR(bad value $@{enableval@} for --enable-debug) ;;
esac],[debug=false])
AM_CONDITIONAL(DEBUG, test x$debug = xtrue)
@end example

ここに@file{Makefile.am}でこの条件文を使用する方法の例を示す。

@example
if DEBUG
DBG = debug
else
DBG =
endif
noinst_PROGRAMS = $(DBG)
@end example

この平凡な例はまたEXTRA_PROGRAMS(@pxref{A Program})を使って処理されても
良い。

@code{if}文では単一の変数だけをテストして良い。@code{else}文は省かれて良
い。条件文はどんな深さにでも入れ子にして良い。

Automakeの条件文はGNU Makeの条件文と同じではないことに注意せよ。Automake
の条件文は@file{configure}スクリプトによって設定時に点検され、
@file{Makefile.in}から@file{Makefile}への変換に影響する。それらは
@file{configure}に渡されたオプションと@file{configure}がホスト・システム
について発見した結果に基く。GNU Makeの条件文はmake時に点検され、makeプロ
グラムに渡された変数や@file{Makefile}で定義された変数に基く。

Automakeの条件文はどんなmakeプログラムでも動作するだろう。

@node Gnits, Cygnus, Conditionals, Top
@chapter @code{--gnu}と@code{--gnits}の影響

@samp{--gnu}オプション(あるいは@samp{AUTOMAKE_OPTIONS}変数の@samp{gnu})
は@code{automake}に以下を点検させる。

@itemize @bullet
@item
ファイル@file{INSTALL}、@file{NEWS}、@file{README}、@file{COPYING}、
@file{AUTHORS}、そして@file{ChangeLog}がパッケージの最上位のディレクトリ
に必要とされる。

@item
オプション@samp{no-installman}と@samp{no-installinfo}が禁止される。
@end itemize

このオプションはもっと点検するように将来拡張されるであろうことに注意せよ。
厳密にGNU標準に必要とされるものに精通することが得策だ。また、
@samp{--gnu}はさまざまな管理者専用のターゲットによって使用されるために、
特定の標準的でないGNUプログラムが存在することを必要とし得る。例えば、将
来@code{pathchk}が@samp{make dist}に必要とされるかもしれない。

@samp{--gnits}オプションは@samp{--gnu}がすることを全てを行い、以下も点検
する。

@itemize @bullet
@item
@samp{make dist}は@file{NEWS}ファイルが現在のバージョンに更新されている
ことを確実にするために点検するだろう。

@item
ファイル@file{COPYING.LIB}が禁止される。LGPLは明らかに失敗した試みと考え
られている。

@item
@samp{VERSION}がその形式がGnits標準に従うことを確実にするために点検され
る。
@c FIXME xref when standards are finished

@item
もし@samp{VERSION}がこれがalphaリリースであると示し、ファイル
@file{README-alpha}がパッケージの最上位のディレクトリに現れれば、配布物
にそれが含められる。これは@samp{--gnits}モードでだけ行われる。なぜなら、
このモードはバージョン・ナンバーの形式が強制される唯一のものだからで、こ
うして@code{automake}が@file{README-alpha}が含められるべきかどうかを自動
的に決定できる唯一のモードなのである。

@item
ファイル@file{THANKS}が必要とされる。
@end itemize


@node Cygnus, Extending, Gnits, Top
@chapter @code{--cygnus}の影響

Cygnus Solutionsは@file{Makefile.in}がどう構築されるのかについて若干異な
る規則を持っている。@code{automake}に@samp{--cygnus}を渡せば、どの生成さ
れた@file{Makefile.in}もCygnus規則に従うようになるだろう。

以下が@samp{--cygnus}の正確な影響である。

@itemize @bullet
@item
infoファイルは常に構築ディレクトリで作成され、ソース・ディレクトリにはな
い。

@item
@file{texinfo.tex}がもしTexinfoのソース・ファイルが指定されれば必要とされ
ない。その仮定はそのファイルは供与されるだろうが、@code{automake}が見付
けられない場所にあるだろうということだ。この仮定はCygnusパッケージが典型
的にまとめられる方法による作り事(artifact)である。

@item
@samp{make dist}はソース・ディレクトリだけでなく構築ディレクトリでもファ
イルを探すだろう。これはinfoファイルを構築ディレクトリに置くことをサポー
トするために必要とされる。

@item
特定のツールがユーザの@samp{PATH}だけでなく構築ツリーでも検索されるだろ
う。これらのツールは@code{runtest}、@code{expect}、@code{makeinfo}と
@code{texi2dvi}である。

@item
@code{--foreign}が暗示される。

@item
オプション@samp{no-installinfo}と@samp{no-dependencies}が暗示される。

@item
マクロ@samp{AM_MAINTAINER_MODE}と@samp{AM_CYGWIN32}が必要とされる。

@item
@code{check}ターゲットが@code{all}に依存しない。
@end itemize

GNU管理者は特別なCygnusモードよりはむしろ@samp{gnu} strictnessを使用する
ことが忠告されている。


@node Extending, Distributing, Cygnus, Top
@chapter Automakeが十分でないとき

Automakeの暗黙の複製意味論は多くの問題が単にいくつかの@code{make}ターゲッ
トや規則を@file{Makefile.in}に加えるだけで取りかかれることを意味する。
@code{automake}はこれらの追加を無視するだろう。

これを行うことに対して、いくつかの警告がある。@code{automake}によってす
でに使用されているターゲットをオーバーロード(overload)することができるが、
それはしばしば勧められない、特にflatでないパッケージの最上位のディレクト
リでは。しかしながら、さまざまな有用なターゲットがあなたの
@file{Makefile.in}で指定できる@samp{-local}バージョンを持っている。
Automakeは標準のターゲットをこれらのユーザが与えたターゲットに補足するだ
ろう。

局所的なバージョンをサポートするターゲットは@code{all}、@code{info}、
@code{dvi}、@code{check}、@code{install-data}、@code{install-exec}、
@code{uninstall}とさまざまな@code{clean}ターゲット(@code{mostlyclean}、
@code{clean}、@code{distclean}と@code{maintainer-clean})である。
@code{uninstall-exec-local}や@code{uninstall-data-local}ターゲットはない
ことに注意せよ。単に@code{uninstall-local}を使いなさい。データだけや実行
形式だけをアンインストールすることは意味をなさない。
@trindex all
@trindex info
@trindex dvi
@trindex check
@trindex install-data
@trindex install-exec
@trindex uninstall

例えば、ここに@file{/etc}のファイルをインストールする一つの方法がある。

@example
install-data-local:
        $(INSTALL_DATA) $(srcdir)/afile /etc/afile
@end example

いくつかのターゲットはまたそれらの作業が行われた後に、@dfn{hook}と呼ばれ
る、他のターゲットを走らせる手段を持つ。hookは基本的なターゲットにちなん
で、@samp{-hook}を付けて名付けられる。hookを許すターゲットは
@code{install-data}、@code{install-exec}、@code{dist}と@code{distcheck}
である。
@trindex install-data-hook
@trindex install-exec-hook
@trindex dist-hook

例えば、ここにインストールされたプログラムにハード・リンクを作成する方法
がある。

@example
install-exec-hook:
        ln $(bindir)/program $(bindir)/proglink
@end example

@c FIXME should include discussion of variables you can use in these
@c rules


@node Distributing, Future, Extending, Top
@chapter @file{Makefile.in}の配布

Automakeは結果として生じる@file{Makefile.in}の配布に何らの制限も設けない。
我々はそれでもなおソフトウェアの作者にGPLのような条件の下で彼らの作品を
配布するよう奨励しているが、そうすることはAutomakeを使用するのに必要とさ
れていない。

@code{--add-missing}スィッチによって自動的にインストールされ得るファイル
の一部はGPLに該当する。それぞれのファイルを見て調べなさい。


@node Future, Index, Distributing, Top
@chapter 将来の考え

ここに将来起きるかもしれないことをいくつか挙げる。

@itemize @bullet
@item
HTMLのサポート。

@item
出力がきれいにされるだろう。例えば、実際に使用される変数だけが生成された
@file{Makefile.in}に現れるだろう。

@item
自動的に配布物をコード化し直すことがサポートされるだろう。その目的は管理
者がどんな文字セットでも一番便利なものを局所的に使用できるが、全ての配布
物をUnicodeやUTF-8符号化の@w{ISO 10646}にするようにすることである。

@item
自動的にパッケージ(例えば、Debianパッケージ、RPMパッケージ、Solarisパッ
ケージ、など)を生成するサポート。これはもしパッケージ構築の経験を持つ誰
かが私に何が便利であるかを教えることができたらより速やかに起きるだろう。

@item
Guileで書き直す。これは近い将来には起きないだろうが、結局は起きるだろう。
@end itemize

@node Index,  , Future, Top
@unnumbered 索引

@printindex cp

@contents
@bye
