File:  [Local Repository] / gnujdoc / automake-1.9 / automake-ja.texi
Revision 1.2: download - view: text, annotated - select for diffs
Sat Jun 4 13:41:33 2005 UTC (15 years, 5 months ago) by futoshi
Branches: MAIN
CVS tags: HEAD
There ara many files. Check ChangeLog ;-p

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

@c @documentlanguage ja

@include automake-v.texi

@copying

This manual is for @acronym{GNU} Automake (version @value{VERSION},
@value{UPDATED}), a program which creates GNU standards-compliant
Makefiles from template files.

Copyright @copyright{} 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
2003, 2004 Free Software Foundation, Inc.

@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the @acronym{GNU} Free Documentation License,
Version 1.1 or any later version published by the Free Software
Foundation; with no Invariant Sections, with the Front-Cover texts
being ``A @acronym{GNU} Manual,'' and with the Back-Cover Texts as in
(a) below.  A copy of the license is included in the section entitled
``@acronym{GNU} Free Documentation License.''

(a) The FSF's Back-Cover Text is: ``You have freedom to copy and
modify this @acronym{GNU} Manual, like @acronym{GNU} software.  Copies
published by the Free Software Foundation raise funds for
@acronym{GNU} development.''
@end quotation
@end copying

@dircategory Software development
@direntry
* automake(ja): (automake-ja).		Making Makefile.in's.
@end direntry

@dircategory Individual utilities
@direntry
* aclocal(ja): (automake-ja)Invoking aclocal.          Generating aclocal.m4.
@end direntry

@titlepage
@title GNU Automake
@subtitle For version @value{VERSION}, @value{UPDATED}
@author David MacKenzie
@author Tom Tromey
@author Alexandre Duret-Lutz
@c 翻訳:西尾 太
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@c Define an index of configure output variables.
@defcodeindex ov
@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 Define an index of commands.
@defcodeindex cm

@c Put the macros and variables into their own index.
@c @syncodeindex fn cp
@syncodeindex ov vr
@syncodeindex cv vr
@syncodeindex fn vr

@c Put everything else into one index (arbitrarily chosen to be the concept index).
@syncodeindex op cp
@syncodeindex tr cp
@syncodeindex cm cp

@ifnottex
@node Top
@comment  node-name,  next,  previous,  up
@top GNU Automake

@insertcopying

@menu
* Introduction::                Automake's purpose
* Generalities::                General ideas
* Examples::                    Some example packages
* Invoking Automake::           Creating a Makefile.in
* configure::                   Scanning configure.ac or configure.in
* Directories::                 Declaring subdirectories
* Programs::                    Building programs and libraries
* Other objects::               Other derived objects
* Other GNU Tools::             Other GNU Tools
* Documentation::               Building documentation
* Install::                     What gets installed
* Clean::                       What gets cleaned
* Dist::                        What goes in a distribution
* Tests::                       Support for test suites
* Rebuilding::                  Automatic rebuilding of Makefile
* Options::                     Changing Automake's behavior
* Miscellaneous::               Miscellaneous rules
* Include::                     Including extra files in an Automake template.
* Conditionals::                Conditionals
* Gnits::                       The effect of @code{--gnu} and @code{--gnits}
* Cygnus::                      The effect of @code{--cygnus}
* Not Enough::                  When Automake is not Enough
* Distributing::                Distributing the Makefile.in
* API versioning::              About compatibility between Automake versions
* Upgrading::                   Upgrading to a Newer Automake Version
* FAQ::                         Frequently Asked Questions
* Copying This Manual::         How to make copies of this manual
* Indices::                     Indices of variables, macros, and concepts

@detailmenu
@c  --- The Detailed Node Listing ---
 --- ノードリストの詳細 ---

@c General ideas
@c 
一般的な考え

* General Operation::           General operation of Automake
* Strictness::                  Standards conformance checking
* Uniform::                     The Uniform Naming Scheme
* Canonicalization::            How derived variables are named
* User Variables::              Variables reserved for the user
* Auxiliary Programs::          Programs automake might require

@c Some example packages
@c 
いくつかのパッケージの例

* Complete::                    A simple example, start to finish
* Hello::                       A classic program
* true::                        Building true and false

@c Scanning @file{configure.ac}
@c 
@file{configure.ac}のスキャン

* Requirements::                Configuration requirements
* Optional::                    Other things Automake recognizes
* Invoking aclocal::            Auto-generating aclocal.m4
* aclocal options::             aclocal command line arguments
* Macro search path::           Modifying aclocal's search path
* Macros::                      Autoconf macros supplied with Automake
* Extending aclocal::           Writing your own aclocal macros
* Local Macros::                Organizing local macros
* Future of aclocal::           aclocal's scheduled death

@c Auto-generating aclocal.m4
@c 
@file{aclocal.m4}の自動生成

* aclocal options::             Options supported by aclocal
* Macro search path::           How aclocal finds .m4 files

@c Autoconf macros supplied with Automake
@c 
Automakeが提供するAutoconfマクロ

* Public macros::               Macros that you can use.
* Private macros::              Macros that you should not use.

@c Directories
@c 
ディレクトリ

* Subdirectories::              Building subdirectories recursively
* Conditional Subdirectories::  Conditionally not building directories
* Alternative::                 Subdirectories without recursion
* Subpackages::                 Nesting packages

@c Building Programs and Libraries
@c 
プログラムとライブラリのビルド

* A Program::                   Building a program
* A Library::                   Building a library
* A Shared Library::            Building a Libtool library
* Program and Library Variables::  Variables controlling program and
                                library builds
* Default _SOURCES::            Default source files
* LIBOBJS::                     Special handling for LIBOBJS and ALLOCA
* Program variables::           Variables used when building a program
* Yacc and Lex::                Yacc and Lex support
* C++ Support::                 Compiling C++ sources
* Assembly Support::            Compiling assembly sources
* Fortran 77 Support::          Compiling Fortran 77 sources
* Fortran 9x Support::          Compiling Fortran 9x sources
* Java Support::                Compiling Java sources
* Support for Other Languages::  Compiling other languages
* ANSI::                        Automatic de-ANSI-fication
* Dependencies::                Automatic dependency tracking
* EXEEXT::                      Support for executable extensions

@c Building a program
@c 
プログラムのビルド

* Program Sources::             Defining program sources
* Linking::                     Linking with libraries or extra objects
* Conditional Sources::         Handling conditional sources
* Conditional Programs::        Building program conditionally

@c Building a Shared Library
@c 
共有ライブラリのビルド

* Libtool Concept::             Introducing Libtool
* Libtool Libraries::           Declaring Libtool Libraries
* Conditional Libtool Libraries::  Building Libtool Libraries Conditionally
* Conditional Libtool Sources::  Choosing Library Sources Conditionally
* Libtool Convenience Libraries::  Building Convenience Libtool Libraries
* Libtool Modules::             Building Libtool Modules
* Libtool Flags::               Using _LIBADD and _LDFLAGS
* LTLIBOBJ::                    Using $(LTLIBOBJ)
* Libtool Issues::              Common Issues Related to Libtool's Use

@c Fortran 77 Support
@c 
Fortran 77のサポート

* Preprocessing Fortran 77::    Preprocessing Fortran 77 sources
* Compiling Fortran 77 Files::  Compiling Fortran 77 sources
* Mixing Fortran 77 With C and C++::  Mixing Fortran 77 With C and C++

@c Mixing Fortran 77 With C and C++
@c 
CとC++と,Fortran 77との混在

* How the Linker is Chosen::    Automatic linker selection

@c Fortran 9x Support
@c 
Fortran 9xのサポート

* Compiling Fortran 9x Files::  Compiling Fortran 9x sources

@c Other Derived Objects
@c 
その他の生成されるオブジェクト

* Scripts::                     Executable scripts
* Headers::                     Header files
* Data::                        Architecture-independent data files
* Sources::                     Derived sources

@c Built sources
@c 
ビルドされているソース

* Built sources example::       Several ways to handle built sources.

@c Other GNU Tools
@c 
その他のGNUツール

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

@c Building documentation
@c 
ドキュメントのビルド

* Texinfo::                     Texinfo
* Man pages::                   Man pages

@c Miscellaneous Rules
@c 
雑多なルール

* Tags::                        Interfacing to etags and mkid
* Suffixes::                    Handling new file extensions
* Multilibs::                   Support for multilibs.

@c When Automake Isn't Enough
@c 
Automakeが十分でないとき

* Extending::                   Adding new rules or overriding existing ones.
* Third-Party Makefiles::       Integrating Non-Automake @file{Makefile}s.

@c Frequently Asked Questions about Automake
@c 
Automakeに関するよくある質問

* CVS::                         CVS and generated files
* maintainer-mode::             missing and AM_MAINTAINER_MODE
* wildcards::                   Why doesn't Automake support wildcards?
* distcleancheck::              Files left in build directory after distclean
* renamed objects::             Why are object files sometimes renamed?
* Multiple Outputs::            Writing rules for tools with many output files

@c Copying This Manual
@c 
このマニュアルのコピーについて

* GNU Free Documentation License::  License for copying this manual

@c Indices
@c 
索引

* Macro and Variable Index::    Index of Autoconf macros and Automake variables
* General Index::               General index

@end detailmenu
@end menu

@end ifnottex


@node Introduction
@c @chapter Introduction
@chapter はじめに

@c Automake is a tool for automatically generating @file{Makefile.in}s from
@c files called @file{Makefile.am}.  Each @file{Makefile.am} is basically a
@c series of @code{make} variable definitions@footnote{These variables are
@c also called @dfn{make macros} in Make terminology, however in this
@c manual we reserve the term @dfn{macro} for Autoconf's macros.}, with
@c rules being thrown in occasionally.  The generated @file{Makefile.in}s
@c are compliant with the GNU Makefile standards.
@c 
Automakeは,@file{Makefile.am}というファイルから,@file{Makefile.in}を
自動的に生成するツールです.それぞれの@file{Makefile.am}は,基本的には
一連の@code{make}変数の定義@footnote{これらの変数は,Makeの用語では
@dfn{makeのマクロ(make macros)}とも呼ばれていますが,このマニュアルで
は,@dfn{マクロ(macro)} はAutoconfのマクロの予約語になっています.}に
なっていて,ルールが時折導入されています.生成された@file{Makefile.in} 
はGNU Makefileの標準に従います.

@cindex GNU Makefile standards

@c The GNU Makefile Standards Document
@c (@pxref{Makefile Conventions, , , standards, The GNU Coding Standards})
@c is long, complicated, and subject to change.  The goal of Automake is to
@c remove the burden of Makefile maintenance from the back of the
@c individual GNU maintainer (and put it on the back of the Automake
@c maintainer).
@c 
GNU Makefile Standards Documentは(@pxref{Makefile Conventions, , ,
standards, The GNU Coding Standards}),長くて複雑で変更の原因にもなり
ます.Automakeの目的は,個別のGNU管理者の背中からMakefle管理の負担を取
り除く(そしてAutomake管理者に任せる)ことです.

@c The typical Automake input file is simply a series of variable definitions.
@c Each such file is processed to create a @file{Makefile.in}.  There
@c should generally be one @file{Makefile.am} per directory of a project.
@c 
一般的なAutomakeの入力ファイルは,単純な一連の変数定義です.それぞれの
ファイルは,@file{Makefile.in}を作成するために処理されます.通常,プロ
ジェクト内のディレクトリごとに,一つの@file{Makefile.am}を配置します.

@cindex Constraints of Automake
@cindex Automake constraints

@c Automake does constrain a project in certain ways; for instance it
@c assumes that the project uses Autoconf (@pxref{Top, , Introduction,
@c autoconf, The Autoconf Manual}), and enforces certain restrictions on
@c the @file{configure.ac} contents@footnote{Older Autoconf versions used
@c @file{configure.in}.  Autoconf 2.50 and greater promotes
@c @file{configure.ac} over @file{configure.in}.  The rest of this
@c documentation will refer to @file{configure.ac}, but Automake also
@c supports @file{configure.in} for backward compatibility.}.
@c 
Automakeは,若干プロジェクトに制限を与えます.例えば,プロジェクトで
Autoconf(@pxref{Top, , Introduction, autoconf, The Autoconf Manual}) 
を使用していると仮定すると,@file{configure.ac}の内容には,ある制限が
生じます@footnote{古いバージョンのAutoconfでは@file{configure.in}を使
用していました.Autoconf 2.50とそれ以降では,@file{configure.in}ではな
く@file{configure.ac}を推奨しています.このドキュメントの残りの部分で
は@file{configure.ac}について説明していますが,後方互換性として
Automake は@file{configure.in}もサポートしています.}.

@cindex Automake requirements
@cindex Requirements, Automake

@c Automake requires @code{perl} in order to generate the
@c @file{Makefile.in}s.  However, the distributions created by Automake are
@c fully GNU standards-compliant, and do not require @code{perl} in order
@c to be built.
@c 
Automakeでは,@file{Makefile.in}を生成するために@code{perl}が必要にな
ります.しかし,Automakeで作成された配布物は完全にGNUの標準に従ってい
て,ビルドするために@code{perl}は不要です.

@cindex BUGS, reporting
@cindex Reporting BUGS
@cindex E-mail, bug reports

@c Mail suggestions and bug reports for Automake to
@c @email{bug-automake@@gnu.org}.
@c 
@email{bug-automake@@gnu.org}宛にAutomakeの提案とバグレポートをメール
してください.


@node Generalities
@c @chapter General ideas
@chapter 一般的な考え

@c The following sections cover a few basic ideas that will help you
@c understand how Automake works.
@c 
以下のセクションで,Automakeが動作する方法を理解することに役立つ,基本
的な考えをいくつか述べます.

@menu
* General Operation::           General operation of Automake
* Strictness::                  Standards conformance checking
* Uniform::                     The Uniform Naming Scheme
* Canonicalization::            How derived variables are named
* User Variables::              Variables reserved for the user
* Auxiliary Programs::          Programs automake might require
@end menu


@node General Operation
@c @section General Operation
@section 一般的な操作

@c Automake works by reading a @file{Makefile.am} and generating a
@c @file{Makefile.in}.  Certain variables and rules defined in the
@c @file{Makefile.am} instruct Automake to generate more specialized code;
@c for instance, a @samp{bin_PROGRAMS} variable definition will cause rules
@c for compiling and linking programs to be generated.
@c 
Automakeは@file{Makefile.am}を読み込み,@file{Makefile.in}を生成します.
@file{Makefile.am}で定義されている変数とルールで,Automake は更に特殊
なコードを生成します.例えば,@samp{bin_PROGRAMS}変数定義で,生成され
るプログラムをコンパイルしてリンクするルールを生成します.

@cindex Non-standard targets
@cindex cvs-dist, non-standard example
@trindex cvs-dist

@c The variable definitions and rules in the @file{Makefile.am} are
@c copied verbatim into the generated file.  This allows you to add
@c arbitrary code into the generated @file{Makefile.in}.  For instance
@c the Automake distribution includes a non-standard rule for the
@c @code{cvs-dist} target, which the Automake maintainer uses to make
@c distributions from his source control system.
@c 
@file{Makefile.am}の変数定義とルールは,そのまま生成されたファイルにコ
ピーされます.これにより,生成される@file{Makefile.in}に任意のコードを
加えることが可能になります.例えばAutomakeの配布物には,Automake管理者
がソースコントロールシステムから配布物を作成するときに使用する,非標準
的な@code{cvs-dist}ターゲットが含まれています.

@cindex GNU make extensions

@c Note that most GNU make extensions are not recognized by Automake.  Using
@c such extensions in a @file{Makefile.am} will lead to errors or confusing
@c behavior.
@c 
ほとんどのGNU makeの拡張は,Automakeが理解しないことに注意してください.
@file{Makefile.am}でこのような拡張を使用すると,エラーが生じたり紛らわ
しい動作をしたりします.

@cindex Append operator
@c A special exception is that the GNU make append operator, @samp{+=}, is
@c supported.  This operator appends its right hand argument to the variable
@c specified on the left.  Automake will translate the operator into
@c an ordinary @samp{=} operator; @samp{+=} will thus work with any make program.
@c 
特別な例外として,GNU makeの追加オペレータの@samp{+=}はサポートされて
います.このオペレータは,その右辺の引数を左辺で指定された変数に追加し
ます.Automakeはそのオペレータを通常の@samp{=}オペレータに変換します.
このため@samp{+=}は,あらゆるmakeプログラムでうまく動作します.

@c Automake tries to keep comments grouped with any adjoining rules or
@c variable definitions.
@c 
Automakeは賢い方法で,ルールや変数定義に隣接しているグループ化されたコ
メントの保持を試みます.

@cindex Make targets, overriding
@cindex Make rules, overriding
@cindex Overriding make rules
@cindex Overriding make targets

@c A rule defined in @file{Makefile.am} generally overrides any such
@c rule of a similar name that would be automatically generated by
@c @code{automake}.  Although this is a supported feature, it is generally
@c best to avoid making use of it, as sometimes the generated rules are
@c very particular.
@c 
一般に,@file{Makefile.am}で定義されているルールは,@code{automake}に
よって自動的に生成されるルールに似た名前を持つものに優先します.これは
サポートされている機能ですが,一般的に,生成されるルールは非常に特殊な
こともあるので,それを利用することは避けたほうがよいでしょう.

@cindex Variables, overriding
@cindex Overriding make variables

@c Similarly, a variable defined in @file{Makefile.am} or
@c @code{AC_SUBST}'ed from @file{configure.ac} will override any
@c definition of the variable that @code{automake} would ordinarily
@c create.  This feature is more often useful than the ability to
@c override a rule.  Be warned that many of the variables generated by
@c @code{automake} are considered to be for internal use only, and their
@c names might change in future releases.
@c 
同様に,@file{Makefile.am}で定義されている変数や@file{configure.ac}で
@code{AC_SUBST}されているものも,@code{automake}が通常作成するあらゆる
変数定義より優先されます.この機能は,ルール優先の機能より役に立つこと
が多いでしょう.@code{automake}で生成された多くの変数は,内部で使用す
ることだけ考慮されていて,それら名前が将来のリリースで変更される可能性
があることに注意しておいてください.

@cindex Recursive operation of Automake
@cindex Automake, recursive operation
@cindex Example of recursive operation

@c When examining a variable definition, Automake will recursively examine
@c variables referenced in the definition.  For example, if Automake is
@c looking at the content of @code{foo_SOURCES} in this snippet
@c 
変数定義を調査しているとき,Automakeは定義で参照されている変数を再帰的
に調査します.例えば,以下の断片的な@code{foo_SOURCES}の内容をAutomake 
が調査している状況を考えます.

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

@c it would use the files @file{a.c}, @file{b.c}, and @file{c.c} as the
@c contents of @code{foo_SOURCES}.
@c 
それは,ファイル@file{a.c},@file{b.c},そして@file{c.c}を
@code{foo_SOURCES}の内容として使用します.

@cindex ## (special Automake comment)
@cindex Special Automake comment
@cindex Comment, special to Automake

@c Automake also allows a form of comment which is @emph{not} copied into
@c the output; all lines beginning with @samp{##} (leading spaces allowed)
@c are completely ignored by Automake.
@c 
Automakeでは,出力ファイルにコピー@emph{されない}コメントの形式も利用
可能です.Automakeは@samp{##}で始まる(スペースの前置は可能です)すべて
の行を完全に無視します.

@c It is customary to make the first line of @file{Makefile.am} read:
@c 
読み込まれる@file{Makefile.am}の最初の行に,以下の行を書くのはいつもの
ことです.

@cindex Makefile.am, first line
@cindex First line of 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 Strictness
@c @section Strictness
@section 厳密さ

@cindex Non-GNU packages

@c While Automake is intended to be used by maintainers of GNU packages, it
@c does make some effort to accommodate those who wish to use it, but do
@c not want to use all the GNU conventions.
@c 
Automakeは,GNUパッケージの管理者が使用することを目的としていますが,
使用したいけれども,すべてのGNU規約を使用したいわけではない人たちをも
受け入れる努力をしています.

@cindex Strictness, defined
@cindex Strictness, foreign
@cindex foreign strictness
@cindex Strictness, gnu
@cindex gnu strictness
@cindex Strictness, gnits
@cindex gnits strictness

@c To this end, Automake supports three levels of @dfn{strictness}---the
@c strictness indicating how stringently Automake should check standards
@c conformance.
@c 
このため,Automakeは三つの@dfn{厳密さ}のレベルをサポートします --- 厳
密さとは,Automakeに調査させる標準への適合度を示すものです.

@c The valid strictness levels are:
@c 
有効な厳密さのレベルは以下のとおりです.

@table @samp
@item foreign
@c Automake will check for only those things which are absolutely
@c required for proper operations.  For instance, whereas GNU standards
@c dictate the existence of a @file{NEWS} file, it will not be required in
@c this mode.  The name comes from the fact that Automake is intended to be
@c used for GNU programs; these relaxed rules are not the standard mode of
@c operation.
@c 
Automakeは,適切な処理のため絶対に必要なものだけを調査します.例えば,
GNUの標準は@file{NEWS}ファイルが存在することを必要としますが,このモー
ドで必要ではありません.この名前(foreign)は,本来はGNUプログラムのため
にAutomakeを使用して欲しいのでこのように名付けられています.これらの緩
い規則は標準的な操作様式ではありません.

@item gnu
@c Automake will check---as much as possible---for compliance to the GNU
@c standards for packages.  This is the default.
@c 
Automakeは,パッケージがGNUの標準に準拠しているかどうか --- 可能な限り 
--- 調査します.これはデフォルトです.

@item gnits
@c Automake will check for compliance to the as-yet-unwritten @dfn{Gnits
@c standards}.  These are based on the GNU standards, but are even more
@c detailed.  Unless you are a Gnits standards contributor, it is
@c recommended that you avoid this option until such time as the Gnits
@c standard is actually published (which may never happen).
@c 
Automakeは,まだ書かれていない@dfn{Gnits standards}に準拠しているかど
うかを調査します.これらはGNUの標準に基づいていますが,より詳しく記述
されています.Gnits standardsの貢献者でない場合,Gnits standardsが実際
に発表されるときまで(発表されることはないかもしれませんが),このオプショ
ンの使用を避けるよう推奨します.
@end table

@c For more information on the precise implications of the strictness
@c level, see @ref{Gnits}.
@c 
厳密さのレベルの正確な意味についての詳細は,@ref{Gnits}を参照してくだ
さい.

@c Automake also has a special ``cygnus'' mode which is similar to
@c strictness but handled differently.  This mode is useful for packages
@c which are put into a ``Cygnus'' style tree (e.g., the GCC tree).  For
@c more information on this mode, see @ref{Cygnus}.
@c 
Automakeには,厳密さに似ていますが異なる扱いを受ける,特殊な``cygnus'' 
モードもあります.このモードは,``Cygnus''形式のツリー(例えば,GCCツリー) 
に配置するパッケージで役に立ちます.このモードの詳細は,@ref{Cygnus}を
参照してください.


@node Uniform
@c @section The Uniform Naming Scheme
@section 一様な命名法

@cindex Uniform naming scheme

@c Automake variables generally follow a @dfn{uniform naming scheme} that
@c makes it easy to decide how programs (and other derived objects) are
@c built, and how they are installed.  This scheme also supports
@c @code{configure} time determination of what should be built.
@c 
Automake変数は,一般に以下の@dfn{一様な命名法(uniform naming scheme)} 
に従っていて,それは,プログラム(とその他の派生されるオブジェクト)のビ
ルド方法と,それらのインストール方法の決定を容易にします.この手法は,
@code{configure}時にビルドするものを決定することもサポートしています.

@cindex _PROGRAMS primary variable
@cindex PROGRAMS primary variable
@cindex Primary variable, PROGRAMS
@cindex Primary variable, defined

@c At @code{make} time, certain variables are used to determine which
@c objects are to be built.  The variable names are made of several pieces
@c which are concatenated together.
@c 
@code{make}時にビルドするオブジェクトを決定するため,特定の変数を使用
します.変数の名前は,いくつかの部品をお互いに連結したものからできてい
ます.

@c The piece which tells automake what is being built is commonly called
@c the @dfn{primary}.  For instance, the primary @code{PROGRAMS} holds a
@c list of programs which are to be compiled and linked.
@c 
ビルドするものをautomakeに伝える部品は,一般に@dfn{プライマリ}と呼ばれ
ています.例えば,プライマリの@code{PROGRAMS}は,コンパイルされリンク
されるプログラムのリストを保持しています.
@vindex PROGRAMS

@cindex pkglibdir, defined
@cindex pkgincludedir, defined
@cindex pkgdatadir, defined

@vindex pkglibdir
@vindex pkgincludedir
@vindex pkgdatadir

@c A different set of names is used to decide where the built objects
@c should be installed.  These names are prefixes to the primary which
@c indicate which standard directory should be used as the installation
@c directory.  The standard directory names are given in the GNU standards
@c (@pxref{Directory Variables, , , standards, The GNU Coding Standards}).
@c Automake extends this list with @code{pkglibdir}, @code{pkgincludedir},
@c and @code{pkgdatadir}; these are the same as the non-@samp{pkg}
@c versions, but with @samp{$(PACKAGE)} appended.  For instance,
@c @code{pkglibdir} is defined as @code{$(libdir)/$(PACKAGE)}.
@c 
ビルドしたオブジェクトをインストールする場所を決定するため,異なる名前
の組が使用されます.これらの名前はプライマリに前置されていて,それはイ
ンストールするディレクトリとして使用される標準的なディレクトリを示して
います.標準的なディレクトリ名はGNUの標準で与えられています
(@pxref{Directory Variables, , , standards, The GNU Coding Standards}).
Automakeは,@code{pkglibdir},@code{pkgincludedir},そして
@code{pkgdatadir}を用いて,このリストを拡張します.これらは非
@samp{pkg}のバージョンと同じですが,@samp{$(PACKAGE)}が付加されます.
例えば,@code{pkglibdir}は@code{$(libdir)/$(PACKAGE)}として定義されま
す.
@cvindex PACKAGE, directory

@cindex EXTRA_, prepending

@c For each primary, there is one additional variable named by prepending
@c @samp{EXTRA_} to the primary name.  This variable is used to list
@c objects which may or may not be built, depending on what
@c @code{configure} decides.  This variable is required because Automake
@c must statically know the entire list of objects that may be built in
@c order to generate a @file{Makefile.in} that will work in all cases.
@c 
それぞれのプライマリに対して,@samp{EXTRA_}をプライマリ名に前置して命
名された追加の変数があります.この変数は,ビルドされたりされなかったり
する可能性のあるオブジェクトのリストで使用され,それは,
@code{configure}が決定したものに依存します.Automakeは,すべての状況で
動作する@file{Makefile.in}を生成するために,ビルドされる可能性のあるオ
ブジェクト全体のリストをあらかじめ知っておく必要があるので,この変数が
必要になります.

@cindex EXTRA_PROGRAMS, defined
@cindex Example, EXTRA_PROGRAMS
@cindex cpio example

@c For instance, @code{cpio} decides at configure time which programs are
@c built.  Some of the programs are installed in @code{bindir}, and some
@c are installed in @code{sbindir}:
@c 
例えば,@code{cpio}はconfigure時にビルドするプログラムを決定します.
@code{bindir}にインストールされるプログラムもあれば,@code{sbindir}に
インストールされるものもあります.

@example
EXTRA_PROGRAMS = mt rmt
bin_PROGRAMS = cpio pax
sbin_PROGRAMS = $(MORE_PROGRAMS)
@end example

@c Defining a primary without a prefix as a variable, e.g.,
@c @code{PROGRAMS}, is an error.
@c 
接頭辞がないプライマリを変数として定義すること,例えば@code{PROGRAMS} 
はエラーになります.

@c Note that the common @samp{dir} suffix is left off when constructing the
@c variable names; thus one writes @samp{bin_PROGRAMS} and not
@c @samp{bindir_PROGRAMS}.
@c 
一般的な@samp{dir}接尾辞は,変数名を作るときには捨てられることに注意し
て下さい.このため,@samp{bindir_PROGRAMS}ではなく,
@samp{bin_PROGRAMS}と書きます.

@c Not every sort of object can be installed in every directory.  Automake
@c will flag those attempts it finds in error.
@c Automake will also diagnose obvious misspellings in directory names.
@c 
すべての種類のオブジェクトが,すべてのディレクトリにインストールされる
わけではありません.Automakeはエラーを見つけたとき,フラグを付けようと
します.Automakeはディレクトリ名での明らかなスペルミスも診断します.

@cindex Extending list of installation directories
@cindex Installation directories, extending list

@c Sometimes the standard directories---even as augmented by Automake---
@c are not enough.  In particular it is sometimes useful, for clarity, to
@c install objects in a subdirectory of some predefined directory.  To this
@c end, Automake allows you to extend the list of possible installation
@c directories.  A given prefix (e.g. @samp{zar}) is valid if a variable of
@c the same name with @samp{dir} appended is defined (e.g. @code{zardir}).
@c 
標準ディレクトリは --- Automakeによって強化されてはいますが --- 十分で
ない場合もあります.特に,前もって定義されているディレクトリのサブディ
レクトリにオブジェクトをインストールすると役に立つこともあります.この
ため,Automakeはインストール可能なディレクトリのリストを拡張することを
可能にします.与えられている接頭辞(例えば@samp{zar})は,同じ名前の変数
に@samp{dir}を付加した変数(例えば@code{zardir})が定義されている場合に
有効です.

@cindex HTML installation, example

@c For instance, installation of HTML files is part of Automake, you could
@c use this to install raw HTML documentation:
@c 
例えば,HTMLファイルのインストールはAutomakeの一部ですが,以下のように
して生のHTMLドキュメントをインストール可能です.

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

@cindex noinst primary prefix, definition

@c The special prefix @samp{noinst} indicates that the objects in question
@c should be built but not installed at all.  This is usually used for
@c objects required to build the rest of your package, for instance static
@c libraries (@pxref{A Library}), or helper scripts.
@c 
特別な接頭辞@samp{noinst}は,該当するオブジェクトをビルドしインストー
ルは決して行なわないことを示します.これは,パッケージ残りのビルドで必
要なオブジェクト,例えば,スタティックライブラリ(@pxref{A Library})や,
補助的なスクリプトに対して有効です.

@cindex check primary prefix, definition

@c The special prefix @samp{check} indicates that the objects in question
@c should not be built until the @code{make check} command is run.  Those
@c objects are not installed either.
@c 
特別な接頭辞@samp{check}は,該当するオブジェクトが@code{make check}コ
マンドが実行されるまでビルドされないことを示します.これらのオブジェク
トはインストールもされません.

@c The current primary names are @samp{PROGRAMS}, @samp{LIBRARIES},
@c @samp{LISP}, @samp{PYTHON}, @samp{JAVA}, @samp{SCRIPTS}, @samp{DATA},
@c @samp{HEADERS}, @samp{MANS}, and @samp{TEXINFOS}.
@c 
現在のプライマリ名は,@samp{PROGRAMS},@samp{LIBRARIES},@samp{LISP},
@samp{PYTHON},@samp{JAVA},@samp{SCRIPTS},@samp{DATA},
@samp{HEADERS},@samp{MANS},そして@samp{TEXINFOS}です.
@vindex PROGRAMS
@vindex LIBRARIES
@vindex LISP
@vindex PYTHON
@vindex JAVA
@vindex SCRIPTS
@vindex DATA
@vindex HEADERS
@vindex MANS
@vindex TEXINFOS

@c Some primaries also allow additional prefixes which control other
@c aspects of @code{automake}'s behavior.  The currently defined prefixes
@c are @samp{dist_}, @samp{nodist_}, and @samp{nobase_}.  These prefixes
@c are explained later (@pxref{Program and Library Variables}).
@c 
@code{automake}の動作の他の側面を制御する,追加の接頭辞が可能なプライ
マリもあります.現在定義されている接頭辞は,@samp{dist_},
@samp{nodist_},そして@samp{nobase_}です.これらの接頭辞は後で説明しま
す(@pxref{Program and Library Variables}).


@node Canonicalization
@c @section How derived variables are named
@section 派生される変数と命名法

@cindex canonicalizing Automake variables

@c Sometimes a Makefile variable name is derived from some text the
@c maintainer supplies.  For instance, a program name listed in
@c @samp{_PROGRAMS} is rewritten into the name of a @samp{_SOURCES}
@c variable.  In cases like this, Automake canonicalizes the text, so that
@c program names and the like do not have to follow Makefile variable naming
@c rules.  All characters in the name except for letters, numbers, the
@c strudel (@@), and the underscore are turned into underscores when making
@c variable references.
@c 
Makefileの変数名は,管理者が提供するいくつかのテキストから派生すること
もあります.例えば,@samp{_PROGRAMS}にリストアップされているプログラム
名は,@samp{_SOURCES}変数の名前にも再び書き込まれます.このような状況
では,プログラム名とそれに類似したものがMakefileの変数命名規則に従う必
要が無いように,Automakeはテキストを標準に従うものにします.名前の中の
文字,数字,アットマーク(@@),そしてアンダースコア以外のすべての文字は,
変数で参照されるときにアンダースコアに変換されます.

@c For example, if your program is named @code{sniff-glue}, the derived
@c variable name would be @code{sniff_glue_SOURCES}, not
@c @code{sniff-glue_SOURCES}.  Similarly the sources for a library named
@c @code{libmumble++.a} should be listed in the
@c @code{libmumble___a_SOURCES} variable.
@c 
例えば,プログラムを@code{sniff-glue}と命名する場合,派生する変数名は,
@code{sniff-glue_SOURCES}ではなく@code{sniff_glue_SOURCES}になります.
同様に,@code{libmumble++.a}と命名されるライブラリのソースは,
@code{libmumble___a_SOURCES}変数にリストアップすべきです.

@c The strudel is an addition, to make the use of Autoconf substitutions in
@c variable names less obfuscating.
@c 
変数名の内部でAutoconfの置換を使用する際にできるだけ明瞭にするため,アッ
トマーク(strudel)が追加されています.


@node User Variables
@c @section Variables reserved for the user
@section ユーザに対して予約されている変数

@cindex variables, reserved for the user
@cindex user variables

@c Some @code{Makefile} variables are reserved by the GNU Coding Standards
@c for the use of the ``user'' -- the person building the package.  For
@c instance, @code{CFLAGS} is one such variable.
@c 
@code{Makefile}変数には,``user''が使用するためにGNU Coding Standards 
で予約されているものもあります -- それはパッケージを構築する人のためで
す.例えば,@code{CFLAGS}はそのような変数の一つです.

@c Sometimes package developers are tempted to set user variables such as
@c @code{CFLAGS} because it appears to make their job easier.  However,
@c the package itself should never set a user variable, particularly not
@c to include switches which are required for proper compilation of the
@c package.  Since these variables are documented as being for the
@c package builder, that person rightfully expects to be able to override
@c any of these variables at build time.
@c 
パッケージ開発者は,明らかに仕事を簡単にするために,@code{CFLAGS}のよ
うなユーザ変数の設定を試みるときもあります.しかし,パッケージ自身でユー
ザ変数を設定すべきではなく,特に,パッケージの適切なコンパイルに要求さ
れるスイッチを含めるべきではありません.これらの変数はパッケージの構築
者に対して説明されるので,人々は,ビルド時にこれらの変数に優先させるこ
とが可能だと期待しています.

@c To get around this problem, automake introduces an automake-specific
@c shadow variable for each user flag variable.  (Shadow variables are not
@c introduced for variables like @code{CC}, where they would make no
@c sense.)  The shadow variable is named by prepending @samp{AM_} to the
@c user variable's name.  For instance, the shadow variable for
@c @code{YFLAGS} is @code{AM_YFLAGS}.
@c 
この問題を解決するため,automakeはそれぞれのユーザフラグ変数に対し,
automake特有の隠れた変数を導入しています.(隠れた変数は,@code{CC}のよ
うな変数に対しては導入されておらず,それは意味が無いためです.)隠れた
変数は,ユーザ変数名に@samp{AM_}を前置して命名されています.例えば,
@code{YFLAGS}に対する隠れた変数は,@code{AM_YFLAGS}になります.


@node Auxiliary Programs
@c @section Programs automake might require
@section automakeが必要とする可能性があるプログラム

@cindex Programs, auxiliary
@cindex Auxiliary programs

@c Automake sometimes requires helper programs so that the generated
@c @file{Makefile} can do its work properly.  There are a fairly large
@c number of them, and we list them here.
@c 
生成された@file{Makefile}が適切に動作するように,automakeが補助的なプ
ログラムを必要とすることもあります.それらは数がかなり多いのですが,こ
こにリストアップします.

@table @code
@item ansi2knr.c
@itemx ansi2knr.1
@c These two files are used by the automatic de-ANSI-fication support
@c (@pxref{ANSI}).
@c 
これらの二つのファイルは,自動的なde-ANSI-ficationのサポートで使用され
ます(@pxref{ANSI}).

@item compile
@c This is a wrapper for compilers which don't accept both @samp{-c} and
@c @samp{-o} at the same time.  It is only used when absolutely required.
@c Such compilers are rare.
@c 
これは,@samp{-c}と@samp{-o}の両方を同時に受け入れることができないコン
パイラに対するラッパーです.それは実際に要求されたときだけ使用されます.
そのようなコンパイラは滅多にありません.

@item config.guess
@itemx config.sub
@c These programs compute the canonical triplets for the given build, host,
@c or target architecture.  These programs are updated regularly to support
@c new architectures and fix probes broken by changes in new kernel
@c versions.  You are encouraged to fetch the latest versions of these
@c files from @url{ftp://ftp.gnu.org/gnu/config/} before making a release.
@c 
これらのプログラムは,与えられているビルド,ホスト,またはターゲットの
アーキテクチャといった,三つの標準的なものを調べます.これらのプログラ
ムは,新しいアーキテクチャのサポートや新しいカーネルでの変更で検査の失
敗を修正するために定期的に更新されています.これらのファイルの最新バー
ジョンを@url{ftp://ftp.gnu.org/gnu/config/}から取得して,リリース物を
作成する前に確かめてください.

@item depcomp
@c This program understands how to run a compiler so that it will generate
@c not only the desired output but also dependency information which is
@c then used by the automatic dependency tracking feature.
@c 
要求された出力だけでなく,自動的な依存性の追跡機能で使用されている依存
情報も生成するために,このプログラムはコンパイラの実行方法を理解します.

@item elisp-comp
@c This program is used to byte-compile Emacs Lisp code.
@c 
このプログラムは,Emacs Lispコードをバイトコンパイルするために使用され
ます.

@item install-sh
@c This is a replacement for the @code{install} program which works on
@c platforms where @code{install} is unavailable or unusable.
@c 
これは,@code{install}プログラムの代わりのもので,@code{install}の利用
や使用が不可能なプラットフォームで動作します.

@item mdate-sh
@c This script is used to generate a @file{version.texi} file.  It examines
@c a file and prints some date information about it.
@c 
このスクリプトは,@file{version.texi}ファイルを生成します.それはファ
イルを調査し,それに関する日付の情報を出力します.

@item missing
@c This wraps a number of programs which are typically only required by
@c maintainers.  If the program in question doesn't exist, @code{missing}
@c prints an informative warning and attempts to fix things so that the
@c build can continue.
@c 
これは,通常管理者だけが必要とするいくつかのプログラムのラッパーです.
該当のプログラムが存在しない場合,@code{missing}は情報を伝える警告を出
力し,ビルドを継続することが可能になるように修正を試みます.

@item mkinstalldirs
@c This script used to be a wrapper around @code{mkdir -p}, which is not
@c portable.  Now we use prefer to use @code{install-sh -d} when configure
@c finds that @code{mkdir -p} does not work, this makes one less script to
@c distribute.
@c 
このスクリプトは移植性が無い@code{mkdir -p}のラッパーです.現在我々は,
@code{mkdir -p}が動作しないことをconfigure時に見つけたとき,
@code{install-sh -d}を使用するようにしていて,これで配布時のスクリプト
が少なくなります.

@c For backward compatibility @code{mkinstalldirs} is still used and
@c distributed when @code{automake} finds it in a package.  But it is no
@c longer installed automatically, and it should be safe to remove it.
@c 
@code{automake}がパッケージで@code{mkinstalldirs}を見つけた時,後方互
換性のため,それはまだ使用され配布されます.しかし,それはもはや自動的
にインストールされず,削除した方が安全でしょう.

@item py-compile
@c This is used to byte-compile Python scripts.
@c 
これは,Pythonスクリプトをバイトコンパイルするために使用されます.

@item texinfo.tex
@c Not a program, this file is required for @code{make dvi}, @code{make ps}
@c and @code{make pdf} to work when Texinfo sources are in the package.
@c 
プログラムではなく,パッケージにTexinfoソースファイルがあるとき,この
ファイルは,@code{make dvi},@code{make ps},そして@code{make pdf}を動
作させるために必要になります.

@item ylwrap
@c This program wraps @code{lex} and @code{yacc} and ensures that, for
@c instance, multiple @code{yacc} instances can be invoked in a single
@c directory in parallel.
@c 
このプログラムは,@code{lex}と@code{yacc}のラッパーで,例えば,複数の
@code{yacc}のインスタンスを単一のディレクトリで,並行して呼び出すこと
が可能であることを確かめます.

@end table


@node Examples
@c @chapter Some example packages
@chapter いくつかのパッケージの例

@menu
* Complete::                    A simple example, start to finish
* Hello::                       A classic program
* true::                        Building true and false
@end menu


@node Complete
@c @section A simple example, start to finish
@section 簡単なサンプル例の最初から最後まで

@cindex Complete example

@c Let's suppose you just finished writing @code{zardoz}, a program to make
@c your head float from vortex to vortex.  You've been using Autoconf to
@c provide a portability framework, but your @file{Makefile.in}s have been
@c ad-hoc.  You want to make them bulletproof, so you turn to Automake.
@c 
さて,渦から渦まで頭を浮かせる(?)プログラムの@code{zardoz}を,たった今
書き終えたと仮定します.移植性のフレームワークを提供するためにAutoconf 
を使用していましたが,@file{Makefile.in}は特別に作成しました.それらを
堅牢にしたいのでAutomakeに切替えてみましょう.

@cindex AM_INIT_AUTOMAKE, example use

@c The first step is to update your @file{configure.ac} to include the
@c commands that @code{automake} needs.  The way to do this is to add an
@c @code{AM_INIT_AUTOMAKE} call just after @code{AC_INIT}:
@c 
第一歩は@code{automake}が必要とするコマンドを含めるため,
@file{configure.ac}の更新を開始します.こうする方法は,@code{AC_INIT} 
の直後に@code{AM_INIT_AUTOMAKE}の呼び出しを加えることです.

@example
AC_INIT(zardoz, 1.0)
AM_INIT_AUTOMAKE
@dots{}
@end example

@c Since your program doesn't have any complicating factors (e.g., it
@c doesn't use @code{gettext}, it doesn't want to build a shared library),
@c you're done with this part.  That was easy!
@c 
プログラムには,(例えば,@code{gettext}を使用していないし,共有ライブ
ラリもビルドしないし)複雑な要因が全くないので,この部分はおしまいです.
なんて簡単なんでしょう!

@cindex aclocal program, introduction
@cindex aclocal.m4, preexisting
@cindex acinclude.m4, defined

@c Now you must regenerate @file{configure}.  But to do that, you'll need
@c to tell @code{autoconf} how to find the new macro you've used.  The
@c easiest way to do this is to use the @code{aclocal} program to generate
@c your @file{aclocal.m4} for you.  But wait@dots{} maybe you already have an
@c @file{aclocal.m4}, because you had to write some hairy macros for your
@c program.  The @code{aclocal} program lets you put your own macros into
@c @file{acinclude.m4}, so simply rename and then run:
@c 
さて@file{configure}を再生成する必要があります.しかしこうするためには,
使用している新しいマクロを見つける方法を@code{autoconf}に伝える必要が
あります.こうするための最も簡単な方法は,@file{aclocal.m4}を生成する
@code{aclocal}プログラムを使用することです.しかしちょっと待って下さい
@dots{}プログラムに対してちょっとマクロを書く必要があり,既に
@file{aclocal.m4}があるかもしれません.@code{aclocal}プログラムでは,
マクロを@file{acinclude.m4}に書いておく必要があるので,単純に名前を変
更して以下のように実行します.

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

@cindex zardoz example

@c Now it is time to write your @file{Makefile.am} for @code{zardoz}.
@c Since @code{zardoz} is a user program, you want to install it where the
@c rest of the user programs go: @code{bindir}.  Additionally,
@c @code{zardoz} has some Texinfo documentation.  Your @file{configure.ac}
@c script uses @code{AC_REPLACE_FUNCS}, so you need to link against
@c @samp{$(LIBOBJS)}.  So here's what you'd write:
@c 
さて@code{zardoz}に対する@file{Makefile.am}を書く時間がやってきました.
@code{zardoz}はユーザプログラムなので,他のユーザプログラムがインストー
ルされる場所にインストールしたいと思います.@code{bindir}です.さらに,
@code{zardoz}にはTexinfoドキュメントもあります.@file{configure.ac}ス
クリプトでは@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

@c Now you can run @code{automake --add-missing} to generate your
@c @file{Makefile.in} and grab any auxiliary files you might need, and
@c you're done!
@c 
さて,@file{Makefile.in}を生成するために@code{automake --add-missing} 
を実行して,必要な補助ファイルを入手して,おしまいです!


@node Hello
@c @section A classic program
@section 古典的なプログラム

@cindex Example, GNU Hello
@cindex Hello example
@cindex GNU Hello, example

@c @uref{ftp://prep.ai.mit.edu/pub/gnu/hello-1.3.tar.gz, GNU hello} is
@c renowned for its classic simplicity and versatility.  This section shows
@c how Automake could be used with the GNU Hello package.  The examples
@c below are from the latest beta version of GNU Hello, but with all of the
@c maintainer-only code stripped out, as well as all copyright comments.
@c 
@uref{ftp://prep.ai.mit.edu/pub/gnu/hello-1.3.tar.gz, GNU hello}は,古
典的単純さと融通性で有名です.このセクションでは,AutomakeをGNU Hello 
パッケージに使用する方法を示します.以下の例は,GNU Helloの最近のベー
タバージョンからのものですが,著作権のコメント全体と同様に,管理者専用
のすべてのコードが取り除かれています.

@c Of course, GNU Hello is somewhat more featureful than your traditional
@c two-liner.  GNU Hello is internationalized, does option processing, and
@c has a manual and a test suite.
@c 
もちろん,GNU Helloは伝統的な二行より幾分長くなっています.GNU Helloは
国際化されていて,オプション処理をして,そしてマニュアルとテストスイー
トもあります.

@cindex configure.ac, from GNU Hello
@cindex GNU Hello, configure.ac
@cindex Hello, configure.ac

@c Here is the @file{configure.ac} from GNU Hello.
@c @strong{Please note:} The calls to @code{AC_INIT} and @code{AM_INIT_AUTOMAKE}
@c in this example use a deprecated syntax.  For the current approach,
@c see the description of @code{AM_INIT_AUTOMAKE} in @ref{Public macros}.
@c 
GNU Helloの@file{configure.ac}は以下のようになっています.@strong{注意
して下さい:} 例にある@code{AC_INIT}と@code{AM_INIT_AUTOMAKE}の呼出は,
推奨されない構文です.現在の手法は,@ref{Public macros}の
@code{AM_INIT_AUTOMAKE}の記述を参照して下さい.

@c FIXME: This definitely requires an update, e.g. to GNU Hello 2.1.1.

@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

@c The @samp{AM_} macros are provided by Automake (or the Gettext library);
@c the rest are standard Autoconf macros.
@c 
@samp{AM_}マクロは,Automake(あるいはGettextライブラリ)によって提供さ
れています.残りは標準的なAutoconfマクロです.


@c The top-level @file{Makefile.am}:
@c 
最上位の@file{Makefile.am}は以下のようになっています.

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

@c As you can see, all the work here is really done in subdirectories.
@c 
御覧のように,ここでの仕事はすべてサブディレクトリで実際に実行されます.

@c The @file{po} and @file{intl} directories are automatically generated
@c using @code{gettextize}; they will not be discussed here.
@c 
@file{po}と@file{intl}ディレクトリは,@code{gettextize}を使用すること
で自動的に生成されます.それらについてはここで述べません.

@cindex Texinfo file handling example
@cindex Example, handling Texinfo files

@c In @file{doc/Makefile.am} we see:
@c 
@file{doc/Makefile.am}は以下のようになっています.

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

@c This is sufficient to build, install, and distribute the GNU Hello
@c manual.
@c 
これで,GNU Helloマニュアルをビルドして,インストールして,そして配布
するには十分です.

@cindex Regression test example
@cindex Example, regression test

@c Here is @file{tests/Makefile.am}:
@c 
@file{tests/Makefile.am}は以下のようになっています.

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

@c The script @file{hello} is generated by @code{configure}, and is the
@c only test case.  @code{make check} will run this test.
@c 
@file{hello}スクリプトは,@code{configure}により生成され,それはテスト
ケースのみで生成されます.@code{make check}でこのテストを実行します.

@cindex INCLUDES, example usage

@c Last we have @file{src/Makefile.am}, where all the real work is done:
@c 
最後は@file{src/Makefile.am}で,実際にすべての仕事が行なわれる場所で
す.
@c FIXME: As all the Hello World excerpts in this manual, this
@c shows deprecated features (here: $(INCLUDES)).

@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 true
@c @section Building true and false
@section trueとfalseのビルド

@cindex Example, false and true
@cindex false Example
@cindex true Example

@c Here is another, trickier example.  It shows how to generate two
@c programs (@code{true} and @code{false}) from the same source file
@c (@file{true.c}).  The difficult part is that each compilation of
@c @file{true.c} requires different @code{cpp} flags.
@c 
以下にもう一つの,トリッキーな例があります.それは同じソースファイル
(@file{true.c})から二つのプログラム(@code{true}と@code{false})を生成す
る方法を示します.難しい部分は,それぞれの@file{true.c}のコンパイルで,
異なる@code{cpp}フラグが必要になるということです.

@example
bin_PROGRAMS = true false
false_SOURCES =
false_LDADD = false.o

true.o: true.c
        $(COMPILE) -DEXIT_CODE=0 -c true.c

false.o: true.c
        $(COMPILE) -DEXIT_CODE=1 -o false.o -c true.c
@end example

@c Note that there is no @code{true_SOURCES} definition.  Automake will
@c implicitly assume that there is a source file named @file{true.c}, and
@c define rules to compile @file{true.o} and link @file{true}.  The
@c @code{true.o: true.c} rule supplied by the above @file{Makefile.am},
@c will override the Automake generated rule to build @file{true.o}.
@c 
@code{true_SOURCES}の定義が無いことに注意してください.Automake は,ソー
スファイル名@file{true.c}が存在すると暗黙に仮定し,@file{true.o}にコン
パイルし,@file{true}にリンクするルールを定義します.上記の
@file{Makefile.am}で提供されている@code{true.o: true.c}のルールは,
Automakeが生成する@file{true.o}をビルドするためのルールに優先します.

@c @code{false_SOURCES} is defined to be empty---that way no implicit value
@c is substituted.  Because we have not listed the source of
@c @file{false}, we have to tell Automake how to link the program.  This is
@c the purpose of the @code{false_LDADD} line.  A @code{false_DEPENDENCIES}
@c variable, holding the dependencies of the @file{false} target will be
@c automatically generated by Automake from the content of
@c @code{false_LDADD}.
@c 
@code{false_SOURCES}は空で定義されています --- その方法では,暗黙の値
で置換されません.@file{false}のソースでリストアップしていないので,プ
ログラムをリンクする方法をAutomakeに伝える必要があります.これが
@code{false_LDADD}行の目的です.@code{false_DEPENDENCIES}変数は
@file{false}ターゲットの依存性を保持していて,@code{false_LDADD}の内容
からAutomakeが自動的に生成されます.

@c The above rules won't work if your compiler doesn't accept both
@c @samp{-c} and @samp{-o}.  The simplest fix for this is to introduce a
@c bogus dependency (to avoid problems with a parallel @code{make}):
@c 
上記のルールは,コンパイラが@samp{-c}と@samp{-o}の両方を受け入れない場
合は動作しません.これを簡単に修正するため,(並行した@code{make}の問題
を避けるために)偽の依存性を導入します.

@example
true.o: true.c false.o
        $(COMPILE) -DEXIT_CODE=0 -c true.c

false.o: true.c
        $(COMPILE) -DEXIT_CODE=1 -c true.c && mv true.o false.o
@end example

@c Also, these explicit rules do not work if the de-ANSI-fication feature
@c is used (@pxref{ANSI}).  Supporting de-ANSI-fication requires a little
@c more work:
@c 
また,これらの明示的なルールは,de-ANSI-ficationが使用される場合は動作
しません(@pxref{ANSI}).de-ANSI-ficationをサポートするためには,もう少
し多くの仕事が必要です.

@example
true_.o: true_.c false_.o
        $(COMPILE) -DEXIT_CODE=0 -c true_.c

false_.o: true_.c
        $(COMPILE) -DEXIT_CODE=1 -c true_.c && mv true_.o false_.o
@end example

@c As it turns out, there is also a much easier way to do this same task.
@c Some of the above techniques are useful enough that we've kept the
@c example in the manual.  However if you were to build @code{true} and
@c @code{false} in real life, you would probably use per-program
@c compilation flags, like so:
@c 
お分かりのように,同じ作業を行なうため,よりいっそう簡単な方法もありま
す.上記のテクニックには,マニュアルの例として残しておくには十分役に立
つものもあります.しかし,@code{true}と@code{false}を現実的にビルドす
る場合は,以下のように,おそらくプログラムごとにコンパイルのフラグを使
用することでしょう.

@example
bin_PROGRAMS = false true

false_SOURCES = true.c
false_CPPFLAGS = -DEXIT_CODE=1

true_SOURCES = true.c
true_CPPFLAGS = -DEXIT_CODE=0
@end example

@c In this case Automake will cause @file{true.c} to be compiled twice,
@c with different flags.  De-ANSI-fication will work automatically.  In
@c this instance, the names of the object files would be chosen by
@c automake; they would be @file{false-true.o} and @file{true-true.o}.
@c (The name of the object files rarely matters.)
@c 
この状況では,Automakeによって,@file{true.c}は異なるフラグで二度コン
パイルされることになります.de-ANSI-ficationは自動的に動作します.この
例では,オブジェクトファイルの名前はautomakeが選択します.それは
@file{false-true.o}と@file{true-true.o}になるでしょう.(オブジェクトファ
イルの名前が問題となることは滅多にありません.)


@node Invoking Automake
@c @chapter Creating a @file{Makefile.in}
@chapter @file{Makefile.in}の生成

@cindex Multiple configure.ac files
@cindex Invoking Automake
@cindex Automake, invoking

@c To create all the @file{Makefile.in}s for a package, run the
@c @code{automake} program in the top level directory, with no arguments.
@c @code{automake} will automatically find each appropriate
@c @file{Makefile.am} (by scanning @file{configure.ac}; @pxref{configure})
@c and generate the corresponding @file{Makefile.in}.  Note that
@c @code{automake} has a rather simplistic view of what constitutes a
@c package; it assumes that a package has only one @file{configure.ac}, at
@c the top.  If your package has multiple @file{configure.ac}s, then you
@c must run @code{automake} in each directory holding a
@c @file{configure.ac}.  (Alternatively, you may rely on Autoconf's
@c @code{autoreconf}, which is able to recurse your package tree and run
@c @code{automake} where appropriate.)
@c 
パッケージに対するすべての@file{Makefile.in}を作成するため,
@code{automake}プログラムを最上位のディレクトリで,引数無しで実行して
ください.@code{automake}は,(@file{configure.ac}をスキャンしながら
@pxref{configure}),自動的にそれぞれ適切な@file{Makefile.am}を見つけ,
対応する@file{Makefile.in}を生成します.@code{automake}では,パッケー
ジを構成するものへの視野がかなり単純になっていることに注意してください.
それは,一つのパッケージにはトップディレクトリにただ一つ
@file{configure.ac}があることを想定しています.パッケージに複数の
@file{configure.ac}がある場合,@file{configure.ac}があるそれぞれのディ
レクトリで@code{automake}を実行する必要があります.(代わりの方法として,
パッケージツリーを巡回して,適切な場所で@code{automake}を実行すること
が可能な,Autoconfの@code{autoreconf}をあてにしてもかまいません.)

@c You can optionally give @code{automake} an argument; @file{.am} is
@c appended to the argument and the result is used as the name of the input
@c file.  This feature is generally only used to automatically rebuild an
@c out-of-date @file{Makefile.in}.  Note that @code{automake} must always
@c be run from the topmost directory of a project, even if being used to
@c regenerate the @file{Makefile.in} in some subdirectory.  This is
@c necessary because @code{automake} must scan @file{configure.ac}, and
@c because @code{automake} uses the knowledge that a @file{Makefile.in} is
@c in a subdirectory to change its behavior in some cases.
@c 
オプションとして@code{automake}に引数を与えることが可能です.
@file{.am}が引数に後置され,その結果が入力ファイルの名前として使用され
ます.この機能は,一般的に,時代遅れの@file{Makefile.in}を自動的にリビ
ルドするためだけに使用します.いくつかのサブディレクトリで
@file{Makefile.in}を再生成するために使用している場合でも,プロジェクト
のトップディレクトリで@code{automake}を実行する必要があることに注意し
てください.これは,@code{automake}は@file{configure.ac}をスキャンする
必要があるため,そして,@code{automake}が状況によってその動作を変更す
るため,@file{Makefile.in}がサブディレクトリに存在するという知識を使用
するためです.

@vindex AUTOCONF
@c Automake will run @code{autoconf} to scan @file{configure.ac} and its
@c dependencies (@file{aclocal.m4}), therefore @code{autoconf} must be in
@c your @code{PATH}.  If there is an @code{AUTOCONF} variable in your
@c environment it will be used instead of @code{autoconf}, this allows you
@c to select a particular version of Autoconf.  By the way, don't
@c misunderstand this paragraph: Automake runs @code{autoconf} to
@c @strong{scan} your @file{configure.ac}, this won't build
@c @file{configure} and you still have to run @code{autoconf} yourself for
@c this purpose.
@c 
Automakeは,@file{configure.ac}をスキャンするためと,その依存性
(@file{aclocal.m4})のため,@code{autoconf}を実行するので,
@code{autoconf}は@code{PATH}に存在する必要があります.@code{AUTOCONF} 
変数が環境変数にある場合,@code{autoconf}の代わりにそれを使用し,これ
で特定のバージョンのAutoconfを選択することが可能になります.ところで,
この段落を誤解しないでください.Automakeは@file{configure.ac}を
@strong{スキャン}するために@code{autoconf}を実行するのであって,
@file{configure}をビルドするわけではありません.この目的に対しては
@code{autoconf}を自分で実行する必要があります.

@cindex Automake options
@cindex Options, Automake
@cindex Strictness, command line

@c @code{automake} accepts the following options:
@c 
@code{automake}は以下のオプションを受け入れます.

@cindex Extra files distributed with Automake
@cindex Files distributed with Automake
@cindex config.guess

@table @samp
@item -a
@itemx --add-missing
@opindex -a
@opindex --add-missing
@c Automake requires certain common files to exist in certain situations;
@c for instance @file{config.guess} is required if @file{configure.ac} runs
@c @code{AC_CANONICAL_HOST}.  Automake is distributed with several of these
@c files (@pxref{Auxiliary Programs}); this option will cause the missing
@c ones to be automatically added to the package, whenever possible.  In
@c general if Automake tells you a file is missing, try using this option.
@c By default Automake tries to make a symbolic link pointing to its own
@c copy of the missing file; this can be changed with @code{--copy}.
@c 
Automakeには,ある共通ファイルが存在することを要求する状況もあります.
例えば,@file{configure.ac}で@code{AC_CANONICAL_HOST}を実行する場合,
@file{config.guess}が必要です.Automakeはこれらのファイルのいくつかと
一緒に配布されています(@pxref{Auxiliary Programs}).このオプションは,
可能であれば,足りないものを自動的にパッケージに加えます.一般的に,
Automakeが足りないファイルがあることを告げる場合,このオプションを使用
してみてください.デフォルトでAutomakeは,足りないファイルを指し示すシ
ンボリックリンクの作成を試みます.これは@code{--copy}で変更可能です.

@c Many of the potentially-missing files are common scripts whose
@c location may be specified via the @code{AC_CONFIG_AUX_DIR} macro.
@c Therefore, @code{AC_CONFIG_AUX_DIR}'s setting affects whether a
@c file is considered missing, and where the missing file is added
@c (@pxref{Optional}).
@c 
足りない可能性のあるファイルの多くは共通スクリプトで,それは
@code{AC_CONFIG_AUX_DIR}マクロで指定した場所に配置してもかまいません.
このため,@code{AC_CONFIG_AUX_DIR}の設定は,ファイルが足りないかどうか
を考慮したり,足りないファイルを追加する場所(@pxref{Optional})に影響し
ます.

@item --libdir=@var{dir}
@opindex --libdir
@c Look for Automake data files in directory @var{dir} instead of in the
@c installation directory.  This is typically used for debugging.
@c 
Automakeのデータファイルを,インストールされたディレクトリではなく
@var{dir}で探します.これは通常,デバッグで使用されます.

@item -c
@opindex -c
@itemx --copy
@opindex --copy
@c When used with @code{--add-missing}, causes installed files to be
@c copied.  The default is to make a symbolic link.
@c 
@code{--add-missing}と一緒に使用するとき,インストールされるファイルを
コピーします.デフォルトではシンボリックリンクを作成します.

@item --cygnus
@opindex --cygnus
@c Causes the generated @file{Makefile.in}s to follow Cygnus rules, instead
@c of GNU or Gnits rules.  For more information, see @ref{Cygnus}.
@c 
GNUやGnitsの規則の代わりに,Cygnusの規則に従う@file{Makefile.in}を生成
します.詳細は,@ref{Cygnus}を参照してください.

@item -f
@opindex -f
@itemx --force-missing
@opindex --force-missing
@c When used with @code{--add-missing}, causes standard files to be reinstalled
@c even if they already exist in the source tree.  This involves removing
@c the file from the source tree before creating the new symlink (or, with
@c @code{--copy}, copying the new file).
@c 
@code{--add-missing}とともに使用するとき,標準のファイルがソースツリー
に存在する場合でもそれらを再インストールします.これで,新しいシンボリッ
クリンクを作成する前に,ソースツリーからファイルを削除します(または,
@code{--copy}とともに使用すると,新しいファイルをコピーします).

@item --foreign
@opindex --foreign
@c Set the global strictness to @samp{foreign}.  For more information, see
@c @ref{Strictness}.
@c 
グローバルな厳密さを@samp{foreign}に設定します.詳細は,
@ref{Strictness}を参照してください.

@item --gnits
@opindex --gnits
@c Set the global strictness to @samp{gnits}.  For more information, see
@c @ref{Gnits}.
@c 
グローバルな厳密さを@samp{gnits}に設定します.詳細は,@ref{Gnits}を参
照してください.

@item --gnu
@opindex --gnu
@c Set the global strictness to @samp{gnu}.  For more information, see
@c @ref{Gnits}.  This is the default strictness.
@c 
グローバルな厳密さを@samp{gnu}に設定します.詳細は,@ref{Gnits}を参照
してください.これはデフォルトの厳密さです.

@item --help
@opindex --help
@c Print a summary of the command line options and exit.
@c 
コマンドラインオプションの概要を出力して終了します.

@item -i
@itemx --ignore-deps
@opindex -i
@c This disables the dependency tracking feature in generated
@c @file{Makefile}s; see @ref{Dependencies}.
@c 
これは,生成される@file{Makefile}での依存性追跡の機能を使用不可能にし
ます.@ref{Dependencies}を参照してください.

@item --include-deps
@opindex --include-deps
@c This enables the dependency tracking feature.  This feature is enabled
@c by default.  This option is provided for historical reasons only and
@c probably should not be used.
@c 
依存性追跡の機能を使用可能にします.この機能は,デフォルトで使用可能で
す.このオプションは歴史的な理由でのみ提供されていて,おそらく使用すべ
きではありません.

@item --no-force
@opindex --no-force
@c Ordinarily @code{automake} creates all @file{Makefile.in}s mentioned in
@c @file{configure.ac}.  This option causes it to only update those
@c @file{Makefile.in}s which are out of date with respect to one of their
@c dependents.
@c 
通常@code{automake}は,@file{configure.ac}で記述されているすべての
@file{Makefile.in}を作成します.このオプションは,依存性の一つの側面を
用いて,時代遅れになっている@file{Makefile.in}だけを更新します.

@item -o @var{dir}
@itemx --output-dir=@var{dir}
@opindex -o
@opindex --output-dir
@c Put the generated @file{Makefile.in} in the directory @var{dir}.
@c Ordinarily each @file{Makefile.in} is created in the directory of the
@c corresponding @file{Makefile.am}.  This option is deprecated and will be
@c removed in a future release.
@c 
生成された@file{Makefile.in}を@var{dir}に配置します.通常,それぞれの
@file{Makefile.in}は,@file{Makefile.am}に対応するディレクトリに作成さ
れます.このオプションの使用は反対で,将来のリリースでは削除されるでしょ
う.

@item -v
@itemx --verbose
@opindex -v
@opindex --verbose
@c Cause Automake to print information about which files are being read or
@c created.
@c 
読み込まれたり作成されたりしているファイルの情報をAutomakeに出力させま
す.

@item --version
@opindex --version
@c Print the version number of Automake and exit.
@c 
Automakeのバージョンナンバーを出力して終了します.

@item -W CATEGORY
@item --warnings=@var{category}
@opindex -W
@opindex --warnings
@c Output warnings falling in @var{category}.  @var{category} can be
@c one of:
@c 
@var{category}にあてはまる警告を出力します.@var{category}は以下の一つ
です.
@table @samp
@item gnu
@c warnings related to the GNU Coding Standards
@c (@pxref{Top, , , standards, The GNU Coding Standards}).
@c 
GNU Coding Standards(@pxref{Top, , , standards, The GNU Coding
Standards})に関連する警告です.
@item obsolete
@c obsolete features or constructions
@c 
時代遅れの機能と構成物です.
@item override
@c user redefinitions of Automake rules or variables
@c 
Automakeのルールと変数のユーザによる再定義.
@item portability
@c portability issues (e.g., use of Make features which are known not portable)
@c 
移植性の問題です(例えば,移植性が無いことが知られているMakeの機能).
@item syntax
@c weird syntax, unused variables, typos
@c 
怪しい構文,未使用の変数,入力ミスです.
@item unsupported
@c unsupported or incomplete features
@c 
サポートされていない,または不完全な機能です.
@item all
@c all the warnings
@c 
すべての警告です.
@item none
@c turn off all the warnings
@c 
すべての警告をオフにします.
@item error
@c treat warnings as errors
@c 
警告をエラーとして処理します.
@end table

@c A category can be turned off by prefixing its name with @samp{no-}.  For
@c instance @samp{-Wno-syntax} will hide the warnings about unused
@c variables.
@c 
カテゴリは,その名前に@samp{no-}を前置することでオフにすることが可能で
す.例えば,@samp{-Wno-syntax}は未使用の変数に関する警告を隠します.

@c The categories output by default are @samp{syntax} and
@c @samp{unsupported}.  Additionally, @samp{gnu} is enabled in @samp{--gnu} and
@c @samp{--gnits} strictness.
@c 
デフォルトで出力されるカテゴリは,@samp{syntax}と@samp{unsupported}で
す.さらに,@samp{gnu}は@samp{--gnu}と@samp{--gnits}の厳密さで有効にな
ります.

@c @samp{portability} warnings are currently disabled by default, but they
@c will be enabled in @samp{--gnu} and @samp{--gnits} strictness in a
@c future release.
@c 
@samp{portability}の警告は,現在デフォルトでは無効になっていますが,将
来のリリースでは,@samp{--gnu}と@samp{--gnits}の厳密さで有効になるでしょ
う.

@vindex WARNINGS
@c The environment variable @samp{WARNINGS} can contain a comma separated
@c list of categories to enable.  It will be taken into account before the
@c command-line switches, this way @samp{-Wnone} will also ignore any
@c warning category enabled by @samp{WARNINGS}.  This variable is also used
@c by other tools like @command{autoconf}; unknown categories are ignored
@c for this reason.
@c 
環境変数@samp{WARNINGS}に,カンマで分けた有効にするカテゴリのリストを
含めることが可能です.それは,コマンドラインスイッチの前に累積され,こ
の方法で@samp{-Wnone}することで,@samp{WARNINGS}で有効にしたすべての警
告カテゴリを無視します.この変数は@command{autoconf}のような他のツール
でも使用されます.このため,未知のカテゴリは無視されます.

@end table


@node configure
@c @chapter Scanning @file{configure.ac}
@chapter @file{configure.ac}のスキャン

@cindex configure.ac, scanning
@cindex Scanning configure.ac

@c Automake scans the package's @file{configure.ac} to determine certain
@c information about the package.  Some @code{autoconf} macros are required
@c and some variables must be defined in @file{configure.ac}.  Automake
@c will also use information from @file{configure.ac} to further tailor its
@c output.
@c 
Automakeは,パッケージに関する特定の情報を決定するために,パッケージの
@file{configure.ac}をスキャンします.必要な@code{autoconf}マクロもあれ
ば,@file{configure.ac}で定義する必要がある変数もあります.Automakeは,
出力物を調整するためにも,@file{configure.ac}からの情報を使用します.

@c Automake also supplies some Autoconf macros to make the maintenance
@c easier.  These macros can automatically be put into your
@c @file{aclocal.m4} using the @code{aclocal} program.
@c 
Automakeは,管理をより容易にするためのAutoconfマクロも提供しています.
これらのマクロは,@code{aclocal}プログラムを使用して自動的に
@file{aclocal.m4}に書き込むことが可能です.

@menu
* Requirements::                Configuration requirements
* Optional::                    Other things Automake recognizes
* Invoking aclocal::            Auto-generating aclocal.m4
* aclocal options::             aclocal command line arguments
* Macro search path::           Modifying aclocal's search path
* Macros::                      Autoconf macros supplied with Automake
* Extending aclocal::           Writing your own aclocal macros
* Local Macros::                Organizing local macros
* Future of aclocal::           aclocal's scheduled death
@end menu


@node Requirements
@c @section Configuration requirements
@section コンフィグレーションの必要条件

@cindex Automake requirements
@cindex Requirements of Automake

@c The one real requirement of Automake is that your @file{configure.ac}
@c call @code{AM_INIT_AUTOMAKE}.  This macro does several things which are
@c required for proper Automake operation (@pxref{Macros}).
@c 
Automakeが本当に必要としていることは一つで,@file{configure.ac}でマク
ロ@code{AM_INIT_AUTOMAKE}を呼び出すことです.このマクロは,適切な
Automakeの処理に必要なことをいくつか行ないます(@pxref{Macros}).
@cvindex AM_INIT_AUTOMAKE

@c Here are the other macros which Automake requires but which are not run
@c by @code{AM_INIT_AUTOMAKE}:
@c 
Automakeは必要としますが,@code{AM_INIT_AUTOMAKE}で実行されないマクロ
には,以下のものがあります.

@table @code
@item AC_CONFIG_FILES
@itemx AC_OUTPUT
@c Automake uses these to determine which files to create (@pxref{Output, ,
@c Creating Output Files, autoconf, The Autoconf Manual}).  A listed file
@c is considered to be an Automake generated @file{Makefile} if there
@c exists a file with the same name and the @file{.am} extension appended.
@c Typically, @code{AC_CONFIG_FILES([foo/Makefile])} will cause Automake to
@c generate @file{foo/Makefile.in} if @file{foo/Makefile.am} exists.
@c 
Automakeは,作成するファイルを決定するためにこれらを使用します
(@pxref{Output, , Creating Output Files, autoconf, The Autoconf
Manual}).同じ名前のファイルが@file{.am}拡張子が後置されている状態で存
在している場合,リストアップされているファイルは,Automakeが
@file{Makefile}を生成するものと考慮します.通常,
@code{AC_CONFIG_FILES([foo/Makefile])}で,@file{foo/Makefile.am}が存在
する場合は,Automakeが@file{foo/Makefile.in} を生成します.

@c When using @code{AC_CONFIG_FILES} with multiple input files, as in
@c @code{AC_CONFIG_FILES([Makefile:top.in:Makefile.in:bot.in])}, Automake
@c will generate the first @file{.in} input file for which a @file{.am}
@c file exists.  If no such file exists the output file is not considered
@c to be Automake generated.
@c 
@code{AC_CONFIG_FILES([Makefile:top.in:Makefile.in:bot.in])}のように,
複数の入力ファイルで@code{AC_CONFIG_FILES}を使用しているとき,Automake 
は,存在する@file{.am}ファイルに対して,最初の@file{.in}入力ファイルを
生成します.そのようなファイルが存在しない場合,出力ファイルはAutomake 
が生成したものと考えません.

@c Files created by @code{AC_CONFIG_FILES} are removed by @code{make distclean}.
@c 
@code{AC_CONFIG_FILES}で生成されたファイルは,@code{make distclean}で
削除されます.
@cvindex AC_CONFIG_FILES
@cvindex AC_OUTPUT
@end table


@node Optional
@c @section Other things Automake recognizes
@section その他のAutomakeが理解すること

@cindex Macros Automake recognizes
@cindex Recognized macros by Automake

@c Every time Automake is run it calls Autoconf to trace
@c @file{configure.ac}.  This way it can recognize the use of certain
@c macros and tailor the generated @file{Makefile.in} appropriately.
@c Currently recognized macros and their effects are:
@c 
Automakeは実行されるたびに,@file{configure.ac}を追跡するために
Autoconfを呼び出します.この方法で,特定のマクロの使用を認識し,生成さ
れる@file{Makefile.in}を適切に調整します.現在認識されるマクロとそれら
の効果は,以下のようになっています.

@table @code
@item AC_CONFIG_HEADERS
@c Automake will generate rules to rebuild these headers.  Older versions
@c of Automake required the use of @code{AM_CONFIG_HEADER}
@c (@pxref{Macros}); this is no longer the case today.
@c 
Automakeはこれらのヘッダをリビルドするルールを生成します.古いバージョ
ンのAutomakeは@code{AM_CONFIG_HEADER}の使用を要求していました
(@pxref{Macros}).これは今日では既に事実ではありません.
@cvindex AC_CONFIG_HEADERS

@item AC_CONFIG_LINKS
@c Automake will generate rules to remove @file{configure} generated links on
@c @code{make distclean} and to distribute named source files as part of
@c @code{make dist}.
@c 
@file{configure}が生成したリンクをAutomakeは@code{make distclean}で削
除し,@code{make dist}の部分で生成される指名されたソースファイルを配布
するためのルールを生成します.
@cvindex AC_CONFIG_LINKS

@item AC_CONFIG_AUX_DIR
@c Automake will look for various helper scripts, such as
@c @file{install-sh}, in the directory named in this macro invocation.
@c 
Automakeは,@file{install-sh}のような様々なヘルパースクリプトを,この
マクロの呼び出しで指定されたディレクトリで探します.
@c This list is accurate relative to version 1.8

@c (The full list of scripts is: @file{config.guess}, @file{config.sub},
@c @file{depcomp}, @file{elisp-comp}, @file{compile}, @file{install-sh},
@c @file{ltmain.sh}, @file{mdate-sh}, @file{missing}, @file{mkinstalldirs},
@c @file{py-compile}, @file{texinfo.tex}, and @file{ylwrap}.)  Not all
@c scripts are always searched for; some scripts will only be sought if the
@c generated @file{Makefile.in} requires them.
@c 
(スクリプトの完全なリストは以下のとおりです.@file{config.guess},
@file{config.sub}, @file{depcomp}, @file{elisp-comp}, 
@file{compile},@file{install-sh}, @file{ltmain.sh}, @file{mdate-sh}, 
@file{missing},@file{mkinstalldirs}, @file{py-compile}, 
@file{texinfo.tex},そして@file{ylwrap})すべてのスクリプトが常に探され
るわけではありません.@file{Makefile.in}の要求で生成された場合だけ探さ
れるスクリプトもあります.
@cvindex AC_CONFIG_AUX_DIR

@c If @code{AC_CONFIG_AUX_DIR} is not given, the scripts are looked for in
@c their @samp{standard} locations.  For @file{mdate-sh},
@c @file{texinfo.tex}, and @file{ylwrap}, the standard location is the
@c source directory corresponding to the current @file{Makefile.am}.  For
@c the rest, the standard location is the first one of @file{.}, @file{..},
@c or @file{../..} (relative to the top source directory) that provides any
@c one of the helper scripts.  @xref{Input, , Finding `configure' Input,
@c autoconf, The Autoconf Manual}.
@c 
@code{AC_CONFIG_AUX_DIR}が与えられていない場合,スクリプトは
@samp{standard}な場所で探されます.@file{mdate-sh},@file{texinfo.tex},
そして@file{ylwrap}の標準的な場所は,現在の@file{Makefile.am}に対応す
るソースディレクトリです.それ以外のものの標準的な場所は,最初は
@file{.},@file{..},または@file{../..}(トップソースディレクトリに関連) 
で,それは経る羽ースクリプトの一つを提供しています.@xref{Input, ,
Finding `configure' Input, autoconf, The Autoconf Manual}.

@c Required files from @code{AC_CONFIG_AUX_DIR} are automatically
@c distributed, even if there is no @file{Makefile.am} in this directory.
@c 
@code{AC_CONFIG_AUX_DIR}で要求されるファイルは,このディレクトリに
@file{Makefile.am}が無い場合でも自動的に配布されます.

@item AC_CANONICAL_HOST
@c Automake will ensure that @file{config.guess} and @file{config.sub}
@c exist.  Also, the @file{Makefile} variables @samp{host_alias} and
@c @samp{host_triplet} are introduced.  See @ref{Canonicalizing, ,
@c Getting the Canonical System Type, autoconf, The Autoconf Manual}.
@c 
Automakeは,@file{config.guess}と@file{config.sub}が確実に存在するよう
にします.また,@file{Makefile}変数の@samp{host_alias}と
@samp{host_triplet}も導入します.@ref{Canonicalizing, , Getting the
Canonical System Type, autoconf, The Autoconf Manual}を参照してくださ
い.
@cvindex AC_CANONICAL_HOST
@vindex host_alias
@vindex host_triplet

@item AC_CANONICAL_SYSTEM
@c This is similar to @code{AC_CANONICAL_HOST}, but also defines the
@c @file{Makefile} variables @samp{build_alias} and @samp{target_alias}.
@c @xref{Canonicalizing, , Getting the Canonical System Type, autoconf, The
@c Autoconf Manual}.
@c 
これは@code{AC_CANONICAL_HOST}に似ていますが,@file{Makefile}変数の
@samp{build_alias}と@samp{target_alias}も定義します.
@xref{Canonicalizing, , Getting the Canonical System Type, autoconf,
The Autoconf Manual}.
@cvindex AC_CANONICAL_SYSTEM
@vindex build_alias
@vindex target_alias

@item AC_LIBSOURCE
@itemx AC_LIBSOURCES
@itemx AC_LIBOBJ
@c Automake will automatically distribute any file listed in
@c @code{AC_LIBSOURCE} or @code{AC_LIBSOURCES}.
@c 
Automakeは,@code{AC_LIBSOURCE}や@code{AC_LIBSOURCES}でリストアップさ
れているすべてのファイルを自動的に配布します.

@c Note that the @code{AC_LIBOBJ} macro calls @code{AC_LIBSOURCE}.  So if
@c an Autoconf macro is documented to call @code{AC_LIBOBJ([file])}, then
@c @file{file.c} will be distributed automatically by Automake.  This
@c encompasses many macros like @code{AC_FUNC_ALLOCA},
@c @code{AC_FUNC_MEMCMP}, @code{AC_REPLACE_FUNCS}, and others.
@c 
@code{AC_LIBOBJS}マクロが@code{AC_LIBSOURCE}を呼び出すことに注意してく
ださい.そのため,Autoconfマクロが@code{AC_LIBOBJ([file])}を呼び出すと
説明されている場合,@file{file.c}はAutomakeで自動的に配布されます.こ
れには,@code{AC_FUNC_ALLOCA},@code{AC_FUNC_MEMCMP},
@code{AC_REPLACE_FUNCS}等の多くのマクロが含まれます.
@cvindex AC_LIBOBJ
@cvindex AC_LIBSOURCE
@cvindex AC_LIBSOURCES

@c By the way, direct assignments to @code{LIBOBJS} are no longer
@c supported.  You should always use @code{AC_LIBOBJ} for this purpose.
@c @xref{AC_LIBOBJ vs LIBOBJS, , @code{AC_LIBOBJ} vs. @code{LIBOBJS},
@c autoconf, The Autoconf Manual}.
@c 
ところで,直接@code{LIBOBJS}に代入することは,既にサポートされていませ
ん.この目的では常に@code{AC_LIBOBJ}を使用すべきです.@xref{AC_LIBOBJ
vs LIBOBJS, , @code{AC_LIBOBJ} vs. @code{LIBOBJS}, autoconf, The
Autoconf Manual}.
@cvindex LIBOBJS

@item AC_PROG_RANLIB
@c This is required if any libraries are built in the package.
@c @xref{Particular Programs, , Particular Program Checks, autoconf, The
@c Autoconf Manual}.
@c 
これは,ライブラリをビルドするパッケージの場合に必要になります.
@xref{Particular Programs, , Particular Program Checks, autoconf, The
Autoconf Manual}.
@cvindex AC_PROG_RANLIB

@item AC_PROG_CXX
@c This is required if any C++ source is included.  @xref{Particular
@c Programs, , Particular Program Checks, autoconf, The Autoconf Manual}.
@c 
これは,C++ソースが含まれる場合に必要になります.@xref{Particular
Programs, , Particular Program Checks, autoconf, The Autoconf Manual}.
@cvindex AC_PROG_CXX

@item AC_PROG_F77
@c This is required if any Fortran 77 source is included.  This macro is
@c distributed with Autoconf version 2.13 and later.  @xref{Particular
@c Programs, , Particular Program Checks, autoconf, The Autoconf Manual}.
@c 
これは,Fortran77ソースが含まれる場合に必要になります.このマクロは
Autoconfのバージョン2.13以降で配布されます.@xref{Particular Programs,
, Particular Program Checks, autoconf, The Autoconf Manual}.
@cvindex AC_PROG_F77

@item AC_F77_LIBRARY_LDFLAGS
@c This is required for programs and shared libraries that are a mixture of
@c languages that include Fortran 77 (@pxref{Mixing Fortran 77 With C and
@c C++}).  @xref{Macros, , Autoconf macros supplied with Automake}.
@c 
これはFortran77を含む言語が混在しているプログラムと共有ライブラリに対
して必要になります(@pxref{Mixing Fortran 77 With C and C++}).
@xref{Macros, , Autoconf macros supplied with Automake}.
@cvindex AC_F77_LIBRARY_LDFLAGS

@item AC_PROG_FC
@c This is required if any Fortran 90/95 source is included.  This macro is
@c distributed with Autoconf version 2.58 and later.  @xref{Particular
@c Programs, , Particular Program Checks, autoconf, The Autoconf Manual}.
@c 
Fortran 90/95ソースが含まれる場合に必要になります.このマクロは
Autoconfのバージョン2.58以降で配布されます.@xref{Particular Programs,
, Particular Program Checks, autoconf, The Autoconf Manual}.
@cvindex AC_PROG_FC

@item AC_PROG_LIBTOOL
@c Automake will turn on processing for @code{libtool} (@pxref{Top, ,
@c Introduction, libtool, The Libtool Manual}).
@c 
Automakeは@code{libtool}に対する処理を開始します(@pxref{Top, ,
Introduction, libtool, The Libtool Manual}).
@cvindex AC_PROG_LIBTOOL

@item AC_PROG_YACC
@c If a Yacc source file is seen, then you must either use this macro or
@c define the variable @samp{YACC} in @file{configure.ac}.  The former is
@c preferred (@pxref{Particular Programs, , Particular Program Checks,
@c autoconf, The Autoconf Manual}).
@c 
Yaccソースファイルがある場合,このマクロを使用するか,
@file{configure.ac}で変数@samp{YACC}を定義する必要があります.前者が好
まれます(@pxref{Particular Programs, , Particular Program Checks,
autoconf, The Autoconf Manual}).
@cvindex AC_PROG_YACC
@cvindex YACC

@item AC_PROG_LEX
@c If a Lex source file is seen, then this macro must be used.
@c @xref{Particular Programs, , Particular Program Checks, autoconf, The
@c Autoconf Manual}.
@c 
Lexソースファイルがある場合,このマクロを使用する必要があります.
@xref{Particular Programs, , Particular Program Checks, autoconf, The
Autoconf Manual}.
@cvindex AC_PROG_LEX

@item AC_SUBST
@cvindex AC_SUBST
@c The first argument is automatically defined as a variable in each
@c generated @file{Makefile.in}.  @xref{Setting Output Variables, , Setting
@c Output Variables, autoconf, The Autoconf Manual}.
@c 
最初の引数は,それぞれの生成される@file{Makefile.in}で,変数として自動
的に定義されます.@xref{Setting Output Variables, , Setting Output
Variables, autoconf, The Autoconf Manual}.

@c If the Autoconf manual says that a macro calls @code{AC_SUBST} for
@c @var{var}, or defines the output variable @var{var} then @var{var} will
@c be defined in each @file{Makefile.in} generated by Automake.
@c E.g. @code{AC_PATH_XTRA} defines @code{X_CFLAGS} and @code{X_LIBS}, so
@c you can use these variables in any @file{Makefile.am} if
@c @code{AC_PATH_XTRA} is called.
@c 
Autoconfマニュアルで,マクロが@var{var}に対して@code{AC_SUBST}を呼び出
すとか,出力変数@var{var}を定義するといった説明がある場合,@var{var}は
それぞれのAutomakeが生成する@file{Makefile.in}で定義されます.例えば,
@code{AC_PATH_XTRA}は@code{X_CFLAGS}と@code{X_LIBS}を定義するので,
@code{AC_PATH_XTRA}が呼び出されている場合,@file{Makefile.am}でこれら
変数と使用することが可能です.

@item AM_C_PROTOTYPES
@c This is required when using automatic de-ANSI-fication; see @ref{ANSI}.
@c 
これは,de-ANSI-ficationを自動的に使用するときに必要です.@ref{ANSI}を
参照してください.
@cvindex AM_C_PROTOTYPES

@item AM_GNU_GETTEXT
@c This macro is required for packages which use GNU gettext
@c (@pxref{gettext}).  It is distributed with gettext.  If Automake sees
@c this macro it ensures that the package meets some of gettext's
@c requirements.
@c 
このマクロはGNU gettextを使うパッケージに対して必要になります
(@pxref{gettext}).それはgettextとともに配布されます.Automakeがこのマ
クロを見つけた場合,このマクロはパッケージがgettextの必要条件のいくつ
かを確実に満たすようにします.
@cvindex AM_GNU_GETTEXT

@item AM_MAINTAINER_MODE
@opindex --enable-maintainer-mode
@c This macro adds a @samp{--enable-maintainer-mode} option to
@c @code{configure}.  If this is used, @code{automake} will cause
@c @samp{maintainer-only} rules to be turned off by default in the
@c generated @file{Makefile.in}s. This macro defines the
@c @samp{MAINTAINER_MODE} conditional, which you can use in your own
@c @file{Makefile.am}.
@c 
このマクロは@code{configure}に@samp{--enable-maintainer-mode}オプショ
ンを加えます.これが使用されている場合,@code{automake}は生成された
@file{Makefile.in}内の@samp{maintainer-only}ルールをデフォルトで停止し
ます.このマクロは@samp{MAINTAINER_MODE}条件を定義し,自分の
@file{Makefile.am}で使用することが可能です.
@cvindex AM_MAINTAINER_MODE

@item m4_include
@cvindex m4_include
@c Files included by @file{configure.ac} using this macro will be
@c detected by Automake and automatically distributed.  They will also
@c appear as dependencies in @file{Makefile} rules.
@c 
@file{configure.ac}でインクルードされるこのマクロを使用しているファイ
ルはAutomakeで検索され,自動的に配布されます.それらは@file{Makefile} 
のルールで依存性として表現されます.

@c @code{m4_include} is seldom used by @file{configure.ac} authors, but
@c can appear in @file{aclocal.m4} when @command{aclocal} detects that
@c some required macros come from files local to your package (as
@c opposed to macros installed in a system-wide directory, see
@c @ref{Invoking aclocal}).
@c 
@code{m4_include}が@file{configure.ac}の著者によって使用されることは滅
多にありませんが,@command{aclocal}がパッケージローカルのファイルにあ
るマクロを要求していることを検出したとき,@file{aclocal.m4}に現れるは
ずです(システム全域のディレクトリにインストールされているマクロとは異
なります.@ref{Invoking aclocal}を参照して下さい).

@end table


@node Invoking aclocal
@c @section Auto-generating aclocal.m4
@section aclocal.m4の自動生成

@cindex Invoking aclocal
@cindex aclocal, Invoking

@c Automake includes a number of Autoconf macros which can be used in
@c your package (@pxref{Macros}); some of them are actually required by
@c Automake in certain situations.  These macros must be defined in your
@c @file{aclocal.m4}; otherwise they will not be seen by
@c @command{autoconf}.
@c 
Automakeには,パッケージで使用可能な多くのAutoconfマクロがあります
(@pxref{Macros}).状況によってはAutomakeが実際に必要とするものもありま
す.これらのマクロは@file{aclocal.m4}で定義する必要があります.さもな
ければ,それらは@code{autoconf}では見つからないでしょう.

@c The @command{aclocal} program will automatically generate
@c @file{aclocal.m4} files based on the contents of @file{configure.ac}.
@c This provides a convenient way to get Automake-provided macros,
@c without having to search around.  The @command{aclocal} mechanism
@c allows other packages to supply their own macros (@pxref{Extending
@c aclocal}).  You can also use it to maintain your own set of custom
@c macros (@pxref{Local Macros}).
@c 
@code{aclocal}プログラムは,@file{configure.ac}の内容に基づいて自動的
に@file{aclocal.m4}ファイルを生成します.これは,Automakeが提供するマ
クロを入手する便利な方法を提供し,それらを探し回る必要がないようになっ
ています.@code{aclocal}のメカニズムで,他のパッケージに対して独自のマ
クロを提供することも可能です(@pxref{Extending aclocal}).また,カスタ
ムマクロの独自セットを管理するためにそれを使用することも可能です
(@pxref{Local Macros}).

@c At startup, @command{aclocal} scans all the @file{.m4} files it can
@c find, looking for macro definitions (@pxref{Macro search path}).  Then
@c it scans @file{configure.ac}.  Any mention of one of the macros found
@c in the first step causes that macro, and any macros it in turn
@c requires, to be put into @file{aclocal.m4}.
@c 
はじめに,@code{aclocal}はマクロ定義を探しながら見つかったすべての
@file{.m4}ファイルをスキャンします(@pxref{Macro search path}).それか
ら@file{configure.ac}をスキャンします.最初のステップで見つかったマク
ロの記述によって,マクロとマクロが要求するファイルを@file{aclocal.m4} 
に書き込みます.

@c @emph{Putting} the file that contains the macro definition into
@c @file{aclocal.m4} is usually done by copying the entire text of this
@c file, including unused macro definitions as well as both @samp{#} and
@c @samp{dnl} comments.  If you want to make a comment which will be
@c completely ignored by @command{aclocal}, use @samp{##} as the comment
@c leader.
@c 
マクロ定義を含むファイルを@file{aclocal.m4}に@emph{書くこと}は,通常こ
のファイルのテキスト全体を,@samp{#}と@samp{dnl}コメントを含め,未使用
のマクロまで含めてコピーすることで実行されます.@code{aclocal}がコメン
トを完全に無視するようにしたい場合は,コメントの最初に@samp{##}を使用
して下さい.

@c When a file selected by @command{aclocal} is located in a subdirectory
@c specified as a relative search path with @command{aclocal}'s @code{-I}
@c argument, @command{aclocal} assumes the file belongs to the package
@c and uses @code{m4_include} instead of copying it into
@c @file{aclocal.m4}.  This makes the package smaller, eases dependency
@c tracking, and cause the file to be distributed automatically.
@c (@pxref{Local Macros} for an example.)  Any macro which is found in a
@c system-wide directory, or via an absolute search path will be copied.
@c So use @code{-I `pwd`/reldir} instead of @code{-I reldir} whenever
@c some relative directory need to be considered outside the package.
@c 
@command{aclocal}が選択しているファイルが@command{aclocal}の@code{-I} 
オプションで相対的なサーチパスで指定されているパッケージのサブディレク
トリに存在するとき,@command{aclocal}はそのファイルがパッケージに属し
ていると仮定し,@file{aclocal.m4}にコピーする代わりに@code{m4_include} 
を使用します.これで,パッケージはより小さくなり,依存性の追跡がより容
易になり,ファイルを自動的に配布物に含めるようになります.(例は,
@pxref{Local Macros}.) システム全体で,または絶対パスで検索され見つかっ
たマクロはコピーされます.そのため,外部パッケージとして考慮する必要が
ある相対的なディレクトリがあるときは,@code{-I reldir}の代わりに
@code{-I `pwd`/reldir}を使用して下さい.

@c The contents of @file{acinclude.m4}, if this file exists, are also
@c automatically included in @file{aclocal.m4}.  We recommend against
@c using @file{acinclude.m4} in new packages (@pxref{Local Macros}).
@c 
@file{acinclude.m4}の内容も,このファイルが存在する場合は自動的に
@file{aclocal.m4}に含められます.我々は,新しいパッケージでの
@file{acinclude.m4}の使用に反対します(@pxref{Local Macros}).

@vindex AUTOM4TE
@c While computing @file{aclocal.m4}, @code{aclocal} runs @code{autom4te}
@c (@pxref{Using autom4te, , Using @code{Autom4te}, autoconf, The
@c Autoconf Manual}) in order to trace the macros which are really used,
@c and omit from @file{aclocal.m4} all macros which are mentioned but
@c otherwise unexpanded (this can happen when a macro is called
@c conditionally).  @code{autom4te} is expected to be in the @code{PATH},
@c just as @code{autoconf}.  Its location can be overridden using the
@c @code{AUTOM4TE} environment variable.
@c 
@file{aclocal.m4}を調べている間,実際に利用されているマクロを追跡し,
記述されているが要望されていないすべてのマクロを@file{aclocal.m4}から
削除するため,@code{aclocal}は@code{autom4te}を実行します(@pxref{Using
autom4te, , Using @code{Autom4te}, autoconf, The Autoconf Manual}).
@code{autom4te}は@code{autoconf}と同じ@code{PATH}にあることを期待され
ています.その場所は,@code{AUTOM4TE}環境変数を使用して優先させること
が可能です.

@menu
* aclocal options::             Options supported by aclocal
* Macro search path::           How aclocal finds .m4 files
@end menu

@node aclocal options
@c @section aclocal options
@section aclocalのオプション

@cindex aclocal, Options
@cindex Options, aclocal

@c @code{aclocal} accepts the following options:
@c 
@code{aclocal}は,以下のオプションを受け入れます.

@table @code
@item --acdir=@var{dir}
@opindex --acdir
@c Look for the macro files in @var{dir} instead of the installation
@c directory.  This is typically used for debugging.
@c 
インストールされたディレクトリの代わりに,@var{dir}でマクロファイルを
探します.これは,通常デバッグで使用します.

@item --help
@opindex --help
@c Print a summary of the command line options and exit.
@c 
コマンドラインオプションの概要を出力し,終了します.

@item -I @var{dir}
@opindex -I
@c Add the directory @var{dir} to the list of directories searched for
@c @file{.m4} files.
@c 
@file{.m4}ファイルを探すディレクトリのリストに,@var{dir}ディレクトリ
を追加します.

@item --force
@opindex --force
@c Always overwrite the output file.  The default is to overwrite the output
@c file only when really needed, i.e., when its contents changes or if one
@c of its dependencies is younger.
@c 
出力ファイルを常に上書きします.デフォルトは,必要なときだけ,すなわち
その内容が変更されたときや,その依存元がより新しい場合,出力ファイルを
上書きします.

@item --output=@var{file}
@opindex --output
@c Cause the output to be put into @var{file} instead of @file{aclocal.m4}.
@c 
@file{aclocal.m4}の代わりに,@var{file}に出力を書き込みます.

@item --print-ac-dir
@opindex --print-ac-dir
@c Prints the name of the directory which @code{aclocal} will search to
@c find third-party @file{.m4} files.  When this option is given, normal
@c processing is suppressed.  This option can be used by a package to
@c determine where to install a macro file.
@c 
サードパーティーの@file{.m4}ファイルを見つけるために@code{aclocal}が検
索するディレクトリの名前を出力します.このオプションが与えられていると
き,標準的な処理は行われません.このオプションは,パッケージがマクロファ
イルをインストールする場所を決定するために使用することが可能です.

@item --verbose
@opindex --verbose
@c Print the names of the files it examines.
@c 
調査しているファイルの名前を出力します.

@item --version
@opindex --version
@c Print the version number of Automake and exit.
@c 
Automakeのバージョンナンバーを出力し,終了します.
@end table

@node Macro search path
@c @section Macro search path
@section マクロ検索パス

@cindex Macro search path
@cindex aclocal search path

@c By default, @command{aclocal} searches for @file{.m4} files in the following
@c directories, in this order:
@c 
デフォルトで,@command{aclocal}は@file{.m4}ファイルを以下のディレクト
リで,この順番に探します.

@table @code
@item @var{acdir-APIVERSION}
@c This is where the @file{.m4} macros distributed with automake itself
@c are stored.  @var{APIVERSION} depends on the automake release used;
@c for automake 1.6.x, @var{APIVERSION} = @code{1.6}.
@c 
これは,automake自身が配布している@file{.m4}マクロを保持している場所で
す.@var{APIVERSION}は,使用しているautomakeのリリースに依存します.
automake 1.6.xに対して,@var{APIVERSION} = @code{1.6}になります.

@item @var{acdir}
@c This directory is intended for third party @file{.m4} files, and is
@c configured when @command{automake} itself is built.  This is
@c @file{@@datadir@@/aclocal/}, which typically
@c expands to @file{$@{prefix@}/share/aclocal/}.  To find the compiled-in
@c value of @var{acdir}, use the @code{--print-ac-dir} option
@c (@pxref{aclocal options}).
@c 
このディレクトリは,サードパーティーの@file{.m4}ファイルが目的で,
@command{automake}自身がビルドされるときにconfigureされます.これは
@file{@@datadir@@/aclocal/}で,通常@file{$@{prefix@}/share/aclocal/}に
展開されます.組み込みの@var{acdir}を知るために,@code{--print-ac-dir} 
オプションを使用してください.@end table

@c As an example, suppose that automake-1.6.2 was configured with
@c @code{--prefix=/usr/local}.  Then, the search path would be:
@c 
例として,automake-1.6.2が@code{--prefix=/usr/local}を用いてconfigure 
されたと仮定します.そのとき検索パスは以下のようになります.

@enumerate
@item @file{/usr/local/share/aclocal-1.6/}
@item @file{/usr/local/share/aclocal/}
@end enumerate

@c As explained in (@pxref{aclocal options}), there are several options that
@c can be used to change or extend this search path.
@c 
(@pxref{aclocal options})で説明したように,この検索パスの変更や拡張で
使用可能なオプションもあります.

@c @subsection Modifying the macro search path: @code{--acdir}
@subsection マクロ検索パスを変更する: @code{--acdir}

@c The most obvious option to modify the search path is
@c @code{--acdir=@var{dir}}, which changes default directory and
@c drops the @var{APIVERSION} directory.  For example, if one specifies
@c @code{--acdir=/opt/private/}, then the search path becomes:
@c 
検索パスを変更する最も明確なオプションは@code{--acdir=@var{dir}}で,デ
フォルトのディレクトリを変更し,@var{APIVERSION}ディレクトリを取り消し
ます.例えば,@code{--acdir=/opt/private/}を指定した場合,検索パスは以
下のようになります.

@enumerate
@item @file{/opt/private/}
@end enumerate

@c Note that this option, @code{--acdir}, is intended for use
@c by the internal automake test suite only; it is not ordinarily
@c needed by end-users.
@c 
このオプション@code{--acdir}の目的は,automakeのテストスイートの内部で
使用することだけです.それはエンドユーザは通常不要です.

@c @subsection Modifying the macro search path: @code{-I @var{dir}}
@subsection マクロ検索パスを変更する: @code{-I @var{dir}}

@c Any extra directories specified using @code{-I} options
@c (@pxref{aclocal options}) are @emph{prepended} to this search list.  Thus,
@c @code{aclocal -I /foo -I /bar} results in the following search path:
@c 
@code{-I}オプション(@pxref{aclocal options})を使用して,あらゆる追加ディ
レクトリを指定することで,これらの検索リストに@emph{前置します}.この
ため,@code{aclocal -I /foo -I /bar}は結果として以下のような検索パスに
なります.

@enumerate
@item @file{/foo}
@item @file{/bar}
@item @var{acdir}-@var{APIVERSION}
@item @var{acdir}
@end enumerate

@c @subsection Modifying the macro search path: @file{dirlist}
@subsection マクロ検索パスを変更する: @file{dirlist}
@cindex @file{dirlist}

@c There is a third mechanism for customizing the search path.  If a
@c @file{dirlist} file exists in @var{acdir}, then that file is assumed to
@c contain a list of directories, one per line, to be added to the search
@c list.  These directories are searched @emph{after} all other
@c directories.
@c 
検索パスをカスタマイズするため,三番目のメカニズムがあります.
@file{dirlist}ファイルが@var{acdir}に存在する場合,そのファイルが,一
行ごとに検索リストに追加するディレクトリリストを含んでいると仮定されま
す.これらのディレクトリは,すべての他のディレクトリの@emph{後に}検索
されます.

@c For example, suppose
@c @file{@var{acdir}/dirlist} contains the following:
@c 
例えば,@file{@var{acdir}/dirlist}が以下の内容を含んでいると仮定します.

@example
/test1
/test2
@end example

@noindent
@c and that @code{aclocal} was called with the @code{-I /foo -I /bar} options.
@c Then, the search path would be
@c 
そして,@code{aclocal}を@code{-I /foo -I /bar}オプションで呼び出したと
仮定します.そのとき検索パスは以下のようになります.

@enumerate
@item @file{/foo}
@item @file{/bar}
@item @var{acdir}-@var{APIVERSION}
@item @var{acdir}
@item @file{/test1}
@item @file{/test2}
@end enumerate

@c If the @code{--acdir=@var{dir}} option is used, then @command{aclocal}
@c will search for the @file{dirlist} file in @var{dir}.  In the
@c @code{--acdir=/opt/private/} example above, @command{aclocal} would look
@c for @file{/opt/private/dirlist}.  Again, however, the @code{--acdir}
@c option is intended for use by the internal automake test suite only;
@c @code{--acdir} is not ordinarily needed by end-users.
@c 
@code{--acdir=@var{dir}}オプションが使用されている場合,
@command{aclocal}は@file{dirlist}ファイルを@var{dir}で検索します.上記
の@code{--acdir=/opt/private/}の例では,@command{aclocal}は
@file{/opt/private/dirlist}を探します.しかし,繰り返しますが,
@code{--acdir}オプションの目的は,automakeのテストスイートの内部で使用
されることだけです.通常,@code{--acdir}はエンドユーザには不要です.

@c @file{dirlist} is useful in the following situation: suppose that
@c @code{automake} version @code{1.6.2} is installed with
@c $prefix=/usr by the system vendor. Thus, the default search
@c directories are
@c 
以下のような状況で,@file{dirlist}は役に立ちます.@code{automake}のバー
ジョン@code{1.6.2}が,@samp{$prefix=/usr}でシステムベンダーによってイ
ンストールされていると仮定します.このためデフォルトの検索ディレクトリ
は以下のようになります.

@enumerate
@item @file{/usr/share/aclocal-1.6/}
@item @file{/usr/share/aclocal/}
@end enumerate

@c However, suppose further that many packages have been manually
@c installed on the system, with $prefix=/usr/local, as is typical.
@c In that case, many of these ``extra'' @file{.m4} files are in
@c @file{/usr/local/share/aclocal}.  The only way to force
@c @file{/usr/bin/aclocal} to find these ``extra'' @file{.m4} files
@c is to always call @code{aclocal -I /usr/local/share/aclocal}.
@c This is inconvenient.  With @file{dirlist}, one may create the file
@c 
しかし,システムには多くのパッケージが,いつも通りに
@samp{$prefix=/usr/local}に手動でインストールされていると仮定します.
この状況では,これらの``追加の''@file{.m4}ファイルは
@file{/usr/local/share/aclocal}にあります.これらの``追加の''
@file{.m4} ファイルを見つけるため,@file{/usr/bin/aclocal}を強制させる
方法は,常に@code{aclocal -I /usr/local/share/aclocal}を呼び出すことで
す.これは不便です.@file{dirlist}を用いると,以下のファイルを作成する
ことができます.

@file{/usr/share/aclocal/dirlist}

@noindent
@c which contains only the single line
@c 
その内容は以下のようになっています.

@file{/usr/local/share/aclocal}

@c Now, the ``default'' search path on the affected system is
@c 
さて,システムに影響する``デフォルト''の検索パスは以下のようになります.

@enumerate
@item @file{/usr/share/aclocal-1.6/}
@item @file{/usr/share/aclocal/}
@item @file{/usr/local/share/aclocal/}
@end enumerate

@c without the need for @code{-I} options; @code{-I} options can be reserved
@c for project-specific needs (@file{my-source-dir/m4/}), rather than
@c using it to work around local system-dependent tool installation
@c directories.
@c 
@code{-I}オプションは不要です.@code{-I}は,ローカルなシステム依存のツー
ルのインストールディレクトリを回避するのではなく,プロジェクト独自のも
のが必要な(@file{my-source-dir/m4/})として予約可能です.

@c Similarly, @file{dirlist} can be handy if you have installed a local
@c copy Automake on your account and want @command{aclocal} to look for
@c macros installed at other places on the system.
@c 
同様に,Automakeのローカルコピーをアカウント内にインストールし,
@command{aclocal}でシステムの他の場所にインストールされているマクロを
探したい場合,@file{dirlist}は手頃なはずです.


@node Macros
@c @section Autoconf macros supplied with Automake
@section Automakeが提供するAutoconfマクロ

@c Automake ships with several Autoconf macros that you can use from your
@c @file{configure.ac}.  When you use one of them it will be included by
@c @code{aclocal} in @file{aclocal.m4}.
@c 
Automakeは,@file{configure.ac}で使用可能ないくつかのAutoconfマクロと
ともに出荷されています.そのうちの一つを使用するとき,@code{aclocal}で
@file{aclocal.m4}に含められるでしょう.

@menu
* Public macros::               Macros that you can use.
* Private macros::              Macros that you should not use.
@end menu

@c consider generating the following subsections automatically from m4 files.

@node Public macros
@c @subsection Public macros
@subsection パブリックマクロ

@table @code
@item AM_CONFIG_HEADER
@c Automake will generate rules to automatically regenerate the config
@c header.  This obsolete macro is a synonym of @code{AC_CONFIG_HEADERS}
@c today (@pxref{Optional}).
@c 
Automakeは,コンフィグヘッダを自動的に再生成するルールを生成します.こ
の時代遅れのマクロは,現在は@code{AC_CONFIG_HEADERS}と同じです
(@pxref{Optional}).
@cvindex AM_CONFIG_HEADER

@item AM_ENABLE_MULTILIB
@c This is used when a ``multilib'' library is being built.  The first
@c optional argument is the name of the @file{Makefile} being generated; it
@c defaults to @samp{Makefile}.  The second option argument is used to find
@c the top source directory; it defaults to the empty string (generally
@c this should not be used unless you are familiar with the internals).
@c @xref{Multilibs}.
@c 
これは,``multilib''ライブラリをビルドするときに使用します.最初のオプ
ション引数は,生成される@file{Makefile}の名前です.デフォルトは
@samp{Makefile}です.二番目のオプション引数は,ソースディレクトリのトッ
プを見つけるために使用します.デフォルトは空の文字列です(内部を理解し
ていない場合,通常はこれを使用しないほうが良いでしょう.)
@xref{Multilibs}.

@item AM_C_PROTOTYPES
@c Check to see if function prototypes are understood by the compiler.  If
@c so, define @samp{PROTOTYPES} and set the output variables @samp{U} and
@c @samp{ANSI2KNR} to the empty string.  Otherwise, set @samp{U} to
@c @samp{_} and @samp{ANSI2KNR} to @samp{./ansi2knr}.  Automake uses these
@c values to implement automatic de-ANSI-fication.
@c 
関数プロトタイプをコンパイラが理解するかどうかを調査します.その場合,
@samp{PROTOTYPES}を定義して,出力変数@samp{U}と@samp{ANSI2KNR}を空の文
字列に設定します.それ以外の場合,@samp{U}を@samp{_}に,
@samp{ANSI2KNR}を@samp{./ansi2knr}にします.Automakeはこれらの値を自動
的なde-ANSI-ficationを実装するために使用します.
@cvindex AM_C_PROTOTYPES

@item AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL
@c If the use of @code{TIOCGWINSZ} requires @file{<sys/ioctl.h>}, then
@c define @code{GWINSZ_IN_SYS_IOCTL}.  Otherwise @code{TIOCGWINSZ} can be
@c found in @file{<termios.h>}.
@c 
@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([OPTIONS])
@itemx AM_INIT_AUTOMAKE(PACKAGE, VERSION, [NO-DEFINE])
@c Runs many macros required for proper operation of the generated Makefiles.
@c 
生成されたMakefileが適切な処理を行なうために必要な多くのマクロを実行し
ます.

@c This macro has two forms, the first of which is preferred.
@c In this form, @code{AM_INIT_AUTOMAKE} is called with a
@c single argument --- a space-separated list of Automake options which should
@c be applied to every @file{Makefile.am} in the tree.  The effect is as if
@c each option were listed in @code{AUTOMAKE_OPTIONS}.
@c 
このマクロには二つの形式があり,最初のものが好まれます.この形式では,
@code{AM_INIT_AUTOMAKE}は単一の引数で呼び出されます --- ツリー内のすべ
ての@file{Makefile.am}に適用するAutomakeオプションのスペースで分離され
ているリストです.それぞれのオプションが@code{AUTOMAKE_OPTIONS}でリス
トアップされているかの様な効果があります.

@c The second, deprecated, form of @code{AM_INIT_AUTOMAKE} has two required
@c arguments: the package and the version number.  This form is
@c obsolete because the @var{package} and @var{version} can be obtained
@c from Autoconf's @code{AC_INIT} macro (which itself has an old and a new
@c form).
@c 
反対されている二番目の@code{AM_INIT_AUTOMAKE}の形式は,二つの引数が必
要です.パッケージとバージョンナンバーです.この形式は,@var{package} 
と@var{version}がAutoconfの@code{AC_INIT}マクロ(それ自身も古い形式と新
しい形式があります)から得ることが可能なので時代遅れです.

@c If your @file{configure.ac} has:
@c 
@file{configure.ac}が以下の場合を考えます.
@example
AC_INIT(src/foo.c)
AM_INIT_AUTOMAKE(mumble, 1.5)
@end example
@c you can modernize it as follows:
@c 
以下のようにして新しいものにすることが可能です.
@example
AC_INIT(mumble, 1.5)
AC_CONFIG_SRCDIR(src/foo.c)
AM_INIT_AUTOMAKE
@end example

@c Note that if you're upgrading your @file{configure.ac} from an earlier
@c version of Automake, it is not always correct to simply move the package
@c and version arguments from @code{AM_INIT_AUTOMAKE} directly to
@c @code{AC_INIT}, as in the example above.  The first argument to
@c @code{AC_INIT} should be the name of your package (e.g. @samp{GNU Automake}),
@c not the tarball name (e.g. @samp{automake}) that you used to pass to
@c @code{AM_INIT_AUTOMAKE}.  Autoconf tries to derive a tarball name from
@c the package name, which should work for most but not all package names.
@c (If it doesn't work for yours, you can use the
@c four-argument form of @code{AC_INIT} --- supported in Autoconf versions
@c greater than 2.52g --- to provide the tarball name explicitly).
@c 
@file{configure.ac}を以前のバージョンのAutomakeから更新している場合,
上記の例のように,単純にパッケージバージョンの引数を,直接
@code{AM_INIT_AUTOMAKE}から@code{AC_INIT}へ移動することが常に正しいと
は限りません.@code{AC_INIT}の最初の引数はパッケージの名前(例えば
@samp{GNU Automake})ですが,@code{AM_INIT_AUTOMAKE}に渡すために使用し
ているtarballの名前(例えば@samp{automake})ではありません.Autoconfはパッ
ケージ名からtarball名を導き出すことを試み,それはほとんどのパッケージ
で動作しますが全てで動作するとは限りません.(うまく動作しない場合 ---
Autoconfのバージョン2.52g以上からサポートされている --- tarball名を明
示的に提供する,@code{AC_INIT}の四つの引数を用いる形式を使用することが
可能です).

@c By default this macro @code{AC_DEFINE}'s @samp{PACKAGE} and
@c @samp{VERSION}.  This can be avoided by passing the @samp{no-define}
@c option, as in:
@c 
デフォルトでこのマクロは@samp{PACKAGE}と@samp{VERSION}を
@code{AC_DEFINE}します.以下のように@samp{no-define}オプションを渡すこ
とでこれを避けることが可能です.
@example
AM_INIT_AUTOMAKE([gnits 1.5 no-define dist-bzip2])
@end example
@c or by passing a third non-empty argument to the obsolete form.
@c 
または時代遅れの形式に空の三番目に引数を渡すことで避けることが可能です.

@cvindex PACKAGE, prevent definition
@cvindex VERSION, prevent definition


@item AM_PATH_LISPDIR
@c Searches for the program @code{emacs}, and, if found, sets the output
@c variable @code{lispdir} to the full path to Emacs' site-lisp directory.
@c 
@code{emacs}プログラムを検索し,見つかった場合は,Emacsのsite-lispディ
レクトリへのフルパスを出力変数@code{lispdir}に設定します.

@c Note that this test assumes the @code{emacs} found to be a version that
@c supports Emacs Lisp (such as @sc{gnu} Emacs or XEmacs).  Other emacsen
@c can cause this test to hang (some, like old versions of MicroEmacs,
@c start up in interactive mode, requiring @samp{C-x C-c} to exit, which
@c is hardly obvious for a non-emacs user).  In most cases, however, you
@c should be able to use @samp{C-c} to kill the test.  In order to avoid
@c problems, you can set @code{EMACS} to ``no'' in the environment, or
@c use the @samp{--with-lispdir} option to @command{configure} to
@c explicitly set the correct path (if you're sure you have an @code{emacs}
@c that supports Emacs Lisp.
@c 
このテストは(@sc{gnu} EmacsやXEmacsのような)Emacs Lispをサポートしてい
るバージョンの@code{emacs}が見つかることを想定しています.それ以外の
emacsenでは,このテストはハングアップします(古いバージョンのMicroEmacs 
のように,対話モードでセットアップされているものは,終了するために
@samp{C-x C-c}が必要で,emacsユーザでなければなかなか気付かないでしょ
う).しかし,ほとんどの状況で,テストを終了するために@samp{C-c}を使用
することが可能でしょう.問題を避けるため,環境変数で@code{EMACS}を
``no''に設定したり,(Emacs Lispをサポートしている@code{emacs}が確実に
ある場合は)正しいパスを明示的に設定するために@command{configure}で
@samp{--with-lispdir}を使用することが可能です.
@cvindex AM_PATH_LISPDIR

@item AM_PROG_AS
@c Use this macro when you have assembly code in your project.  This will
@c choose the assembler for you (by default the C compiler) and set
@c @code{CCAS}, and will also set @code{CCASFLAGS} if required.
@c 
プロジェクトにアセンブラコードがあるときは,このマクロを使用して下さい.
これはアセンブラを選択し(デフォルトはCコンパイラ),@code{CCAS}を設定し,
そして,必要な場合は@code{CCASFLAGS}も設定します.

@item AM_PROG_CC_C_O
@c This is like @code{AC_PROG_CC_C_O}, but it generates its results in the
@c manner required by automake.  You must use this instead of
@c @code{AC_PROG_CC_C_O} when you need this functionality.
@c 
これは@code{AC_PROG_CC_C_O}に似ていますが,それはautomakeが要求する形
式の結果を生成します.この機能が必要なときは,@code{AC_PROG_CC_C_O}の
代わりにこれを使用して下さい.

@item AM_PROG_LEX
@cindex HP-UX 10, lex problems
@cindex lex problems with HP-UX 10
@c Like @code{AC_PROG_LEX} (@pxref{Particular Programs, , Particular
@c Program Checks, autoconf, The Autoconf Manual}), but uses the
@c @code{missing} script on systems that do not have @code{lex}.
@c @samp{HP-UX 10} is one such system.
@c 
@code{AC_PROG_LEX}に似ていますが(@pxref{Particular Programs, ,
Particular Program Checks, autoconf, The Autoconf Manual}),@code{lex} 
が無いシステムで@code{missing}スクリプトを使用します.@samp{HP-UX 10} 
はそのようなシステムの一つです.

@item AM_PROG_GCJ
@c This macro finds the @code{gcj} program or causes an error.  It sets
@c @samp{GCJ} and @samp{GCJFLAGS}.  @code{gcj} is the Java front-end to the
@c GNU Compiler Collection.
@c 
このマクロは,@code{gcj}プログラムを見つけるか,そうでなければエラーを
発生します.それは@samp{GCJ}と@samp{GCJFLAGS}を設定します.@code{gcj} 
は,GNU Compiler CollectionのJavaフロントエンドです.
@cvindex AM_PROG_GCJ

@item AM_SYS_POSIX_TERMIOS
@cvindex am_cv_sys_posix_termios
@cindex POSIX termios headers
@cindex termios POSIX headers
@c Check to see if POSIX termios headers and functions are available on the
@c system.  If so, set the shell variable @code{am_cv_sys_posix_termios} to
@c @samp{yes}.  If not, set the variable to @samp{no}.
@c 
POSIX termiosヘッダと関数がシステムで利用可能かどうか調査します.その
場合,シェル変数@code{am_cv_sys_posix_termios}を@samp{yes}に設定します.
そうでない場合,その変数を@samp{no}に設定します.

@item AM_WITH_DMALLOC
@cvindex WITH_DMALLOC
@cindex dmalloc, support for
@opindex --with-dmalloc
@c Add support for the
@c @uref{ftp://ftp.letters.com/src/dmalloc/dmalloc.tar.gz, dmalloc}
@c package.  If the user configures with @samp{--with-dmalloc}, then define
@c @code{WITH_DMALLOC} and add @samp{-ldmalloc} to @code{LIBS}.
@c 
@uref{ftp://ftp.letters.com/src/dmalloc/dmalloc.tar.gz, dmalloc}パッケー
ジに対するサポートを追加します.ユーザが@samp{--with-demalloc}を用いて
configureする場合,@code{WITH_DMALLOC}を定義し,@code{LIBS}に
@samp{-ldmalloc}を加えます.

@item AM_WITH_REGEX
@cvindex WITH_REGEX
@opindex --with-regex
@cindex regex package
@cindex rx package
@c Adds @samp{--with-regex} to the @code{configure} command line.  If
@c specified (the default), then the @samp{regex} regular expression
@c library is used, @file{regex.o} is put into @samp{LIBOBJS}, and
@c @samp{WITH_REGEX} is defined.  If @samp{--without-regex} is given, then
@c the @samp{rx} regular expression library is used, and @file{rx.o} is put
@c into @samp{LIBOBJS}.
@c 
@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} 
に書き込まれます.

@end table

@node Private macros
@c @subsection Private macros
@subsection プライベートマクロ

@c The following macros are private macros you should not call directly.
@c They are called by the other public macros when appropriate.  Do not
@c rely on them, as they might be changed in a future version.  Consider
@c them as implementation details; or better, do not consider them at all:
@c skip this section!
@c 
以下のマクロは,直接呼び出すべきではないプライベートマクロです.それら
は適切なときに他のパブリックマクロから呼び出されます.将来のバージョン
で変更される可能性があるので,それらを呼び出さないでください.それらは
実装の詳細を考察するものと考えてください.または,何も考えないほうが良
いかもしれません.このセクションは読み飛ばしてください!

@table @code
@item _AM_DEPENDENCIES
@itemx AM_SET_DEPDIR
@itemx AM_DEP_TRACK
@itemx AM_OUTPUT_DEPENDENCY_COMMANDS
@c These macros are used to implement Automake's automatic dependency
@c tracking scheme.  They are called automatically by automake when
@c required, and there should be no need to invoke them manually.
@c 
これらのマクロはAutomakeの自動的な依存性の追跡手法を実装するために使用
されます.それらは,要求されたときAutomakeから自動的に呼び出され,手動
で呼び出す必然性はありません.

@item AM_MAKE_INCLUDE
@c This macro is used to discover how the user's @code{make} handles
@c @code{include} statements.  This macro is automatically invoked when
@c needed; there should be no need to invoke it manually.
@c 
このマクロは,ユーザの@code{make}が@code{include}文を処理する方法を知
るために使用されます.それらは,必要なとき自動的に呼び出されます.手動
で呼び出す必然性はありません.

@item AM_PROG_INSTALL_STRIP
@c This is used to find a version of @code{install} which can be used to
@c @code{strip} a program at installation time.  This macro is
@c automatically included when required.
@c 
これは,インストール時にプログラムを@code{strip}するために使用可能な
@code{install}のバージョンを知るために使用されます.このマクロは要求さ
れるとき自動的にインクルードされます.

@item AM_SANITY_CHECK
@c This checks to make sure that a file created in the build directory is
@c newer than a file in the source directory.  This can fail on systems
@c where the clock is set incorrectly.  This macro is automatically run
@c from @code{AM_INIT_AUTOMAKE}.
@c 
これは,ビルドディレクトリに作成されるファイルがソースディレクトリのファ
イルより確実に新しいことを調査します.時計の設定が正しくないシステムで
失敗するはずです.このマクロは@code{AM_INIT_AUTOMAKE}から自動的に実行
されます.

@end table


@node Extending aclocal
@c @section Writing your own aclocal macros
@section 独自のaclocalマクロを書く

@cindex aclocal, extending
@cindex Extending aclocal

@c The @command{aclocal} program doesn't have any built-in knowledge of any
@c macros, so it is easy to extend it with your own macros.
@c 
@command{aclocal}プログラムには,マクロ組み込みの知識が全く無いので,
独自のマクロでそれを拡張することは容易です.

@c This can be used by libraries which want to supply their own Autoconf
@c macros for use by other programs.  For instance the @command{gettext}
@c library supplies a macro @code{AM_GNU_GETTEXT} which should be used by
@c any package using @command{gettext}.  When the library is installed, it
@c installs this macro so that @command{aclocal} will find it.
@c 
これは,他のプログラムで使用する独自のAutoconfマクロを,供給したいライ
ブラリに対して使用することが可能です.例えば@code{gettext}ライブラリは,
@code{gettext}を使用しているあらゆるパッケージで使用されるように,
@code{AM_GNU_GETTEXT}マクロを提供しています.ライブラリがインストール
されるとき,@code{aclocal}で見つかるように,このマクロをインストールし
ます.

@c A macro file's name should end in @file{.m4}.  Such files should be
@c installed in @file{$(datadir)/aclocal}.  This is as simple as writing:
@c 
マクロファイルの名前は@file{.m4}で終わらせすべきです.そのようなファイ
ルは@file{$(datadir)/aclocal}にインストールされます.簡単に書くと以下
のようになります.

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

@c A file of macros should be a series of properly quoted
@c @code{AC_DEFUN}'s (@pxref{Macro Definitions, , , autoconf, The
@c Autoconf Manual}).  The @command{aclocal} programs also understands
@c @code{AC_REQUIRE} (@pxref{Prerequisite Macros, , , autoconf, The
@c Autoconf Manual}), so it is safe to put each macro in a separate file.
@c Each file should have no side effects but macro definitions.
@c Especially, any call to @code{AC_PREREQ} should be done inside the
@c defined macro, not at the beginning of the file.
@c 
マクロのファイルは,@code{AC_DEFUN} (@pxref{Macro Definitions, , ,
autoconf, The Autoconf Manual})で適切に引用符で囲むべきです.
@command{aclocal}プログラムは@code{AC_REQUIRE} (@pxref{Prerequisite
Macros, , , autoconf, The Autoconf Manual})も理解するので,個別のファ
イルのそれぞれのマクロに書き込んでも大丈夫です.それぞれのファイルには
マクロ定義以外の副作用が無いようにすべきです.特に,@code{AC_PREREQ}の
呼び出しは,マクロ定義内部にすべきでファイルの最初に書くべきではありま
せん.

@cindex underquoted AC_DEFUN
@cvindex AC_DEFUN
@cvindex AC_PREREQ

@c Starting with Automake 1.8, @command{aclocal} will warn about all
@c underquoted calls to @code{AC_DEFUN}.  We realize this will annoy a
@c lot of people, because @command{aclocal} was not so strict in the past
@c and many third party macros are underquoted; and we have to apologize
@c for this temporary inconvenience.  The reason we have to be stricter
@c is that a future implementation of @command{aclocal} (@pxref{Future of
@c aclocal}) will have to temporary include all these third party
@c @file{.m4} files, maybe several times, even those which are not
@c actually needed.  Doing so should alleviate many problem of the
@c current implementation, however it requires a stricter style from the
@c macro authors.  Hopefully it is easy to revise the existing macros.
@c For instance
@c 
Automake 1.8から,@command{aclocal}は,引用符で囲まれていない
@code{AC_DEFUN}の呼び出しすべてに警告を発するようになっています.我々
はこれで,人々がうんざりすることを自覚していて,それは
@command{aclocal}はこれまであまり厳密ではなく,多くのサードパーティー
のマクロは引用符で囲まれていないためです.そして我々は,この一時的な不
便さを謝罪しなければなりません.我々が厳密にする必要がある理由は,将来
の@command{aclocal} (@pxref{Future of aclocal})の実装で,一時的にこれ
らすべてのサードパーティーの@file{.m4}ファイルを,可能性としては複数回,
不要なものであっても,インクルードする必要があるためです.そうすること
で,多少なりとも現在の実装では多くの問題があるのですが,より厳密な形式
をマクロの著者に要求することになります.希望としては,既存のマクロを
ちょっと修正して欲しいと思っています.例えば以下のようにします.
@example
# bad style
AC_PREREQ(2.57)
AC_DEFUN(AX_FOOBAR,
[AC_REQUIRE([AX_SOMETHING])dnl
AX_FOO
AX_BAR
])
@end example
@noindent
@c should be rewritten as
@c 
以下のように書き換えるべきです.
@example
AC_DEFUN([AX_FOOBAR],
[AC_PREREQ(2.57)dnl
AC_REQUIRE([AX_SOMETHING])dnl
AX_FOO
AX_BAR
])
@end example

@c Wrapping the @code{AC_PREREQ} call inside the macro ensures that
@c Autoconf 2.57 will not be required if @code{AX_FOOBAR} is not actually
@c used.  Most importantly, quoting the first argument of @code{AC_DEFUN}
@c allows the macro to be redefined or included twice (otherwise this
@c first argument would be expansed during the second definition).
@c 
@code{AC_PREREQ}の呼出をマクロ内にラップすることで,Autoconf 2.57は,
@code{AX_FOOBAR}を実際に使用しない場合は要求しなくなります.最も重要な
ことは,@code{AC_DEFUN}の最初の引数を引用符で囲むことで,マクロを再定
義したり,二回インクルードすることが可能になります(そうしなければ,こ
の最初の引数は二番目の定義の間展開されたままです).

@c If you have been directed here by the @command{aclocal} diagnostic but
@c are not the maintainer of the implicated macro, you will want to
@c contact the maintainer of that macro.  Please make sure you have the
@c last version of the macro and that the problem already hasn't been
@c reported before doing so: people tend to work faster when they aren't
@c flooded by mails.
@c 
このような@command{aclocal}の診断が示された場合,マクロ実装の管理者で
はない場合,マクロの管理者に連絡したいかもしれません.マクロの最新バー
ジョンと,そのような報告が以前になされていないことを確認ししてください.
人は,メールの洪水がないときには,すぐにでも仕事をするものです.

@c Another situation where @command{aclocal} is commonly used is to
@c manage macros which are used locally by the package, @ref{Local
@c Macros}.
@c 
@command{aclocal}を一般的に使用するもう一つの状況は,パッケージローカ
ルのマクロを管理するときです.@ref{Local Macros}を参照して下さい.

@node Local Macros
@c @section Handling Local Macros
@section ローカルなマクロの処理

@c Feature tests offered by Autoconf do not cover all needs.  People
@c often have to supplement existing tests with their own macros, or
@c with third-party macros.
@c 
Autoconfで提案される機能テストは,すべてのニーズをカバーしていません.
独自のマクロやサードパーティーのマクロで既存のテストを補足する必要があ
ることもよくあります.

@c There are two ways to organize custom macros in a package.
@c 
パッケージのカスタムマクロを体系付ける方法は二つあります.

@c The first possibility (the historical practice) is to list all your
@c macros in @file{acinclude.m4}.  This file will be included in
@c @file{aclocal.m4} when you run @command{aclocal}, and its macro(s) will
@c henceforth be visible to @command{autoconf}.  However if it contains
@c numerous macros, it will rapidly become difficult to maintain, and it
@c will be almost impossible to share macros between packages.
@c 
利用可能な最初の方法は(歴史的な手法で)すべてのマクロを
@file{acinclude.m4}にリストアップすることです.このファイルは
@command{aclocal}の実行時に@file{aclocal.m4}に含められ,そのマクロはそ
れ以降@command{autoconf}から見えるようになります.しかし,たくさんのマ
クロを含んでいる場合,ちょっとした管理が難しくなり,パッケージ間でマク
ロを共有することが不可能になります.

@vindex ACLOCAL_AMFLAGS
@c The second possibility, which we do recommend, is to write each macro
@c in its own file and gather all these files in a directory.  This
@c directory is usually called @file{m4/}.  To build @file{aclocal.m4},
@c one should therefore instruct @command{aclocal} to scan @file{m4/}.
@c From the command line, this is done with @code{aclocal -I m4}.  The
@c top-level @file{Makefile.am} should also be updated to define
@c 
利用可能な二番めの方法は,こちらが推奨されていますが,それぞれのマクロ
を単独ファイルに書き,一つのディレクトリにこれらすべてのファイルをまと
めておくことです.このディレクトリは通常@file{m4/}と呼ばれています.こ
のため,@file{aclocal.m4}をビルドする際,@command{aclocal}に@file{m4/}
をスキャンするように指示するべきです.コマンドラインからは,
@code{aclocal -I m4}とします.または,最上位のの@file{Makefile.am}の定
義を以下のように更新すべきです.

@example
 ACLOCAL_AMFLAGS = -I m4
@end example

@c @code{ACLOCAL_AMFLAGS} contains options to pass to @command{aclocal}
@c when @file{aclocal.m4} is to be rebuilt by @code{make}.  This line is
@c also used by @command{autoreconf} (@pxref{autoreconf Invocation, ,
@c Using @command{autoreconf} to Update @file{configure} Scripts,
@c autoconf, The Autoconf Manual}) to run @command{aclocal} with suitable
@c options, or by @command{autopoint} (@pxref{autopoint Invocation, ,
@c Invoking the @command{autopoint} Program, gettext, GNU gettext tools})
@c and @command{gettextize} (@pxref{gettextize Invocation, , Invoking the
@c @command{gettextize} Program, gettext, GNU gettext tools}) to locate
@c the place where Gettext's macros should be installed.  So even if you
@c do not really care about the rebuild rules, you should define
@c @code{ACLOCAL_AMFLAGS}.
@c 
@code{ACLOCAL_AMFLAGS}は,@file{aclocal.m4}が@code{make}でリビルドされ
るとき,@command{aclocal}に渡すオプションを含んでいます.この行は,適
切なオプションで@command{aclocal}を実行するため,@command{autoreconf}
(@pxref{autoreconf Invocation, , Using @command{autoreconf} to Update
@file{configure} Scripts, autoconf, The Autoconf Manual})や,Gettextの
マクロがインストールされている場所を示すため@command{autopoint}
(@pxref{autopoint Invocation, , Invoking the @command{autopoint}
Program, gettext, GNU gettext tools})と@command{gettextize}
(@pxref{gettextize Invocation, , Invoking the @command{gettextize}
Program, gettext, GNU gettext tools})でも使用されます.そのため,リビ
ルドのルールであまり注意していなくても,@code{ACLOCAL_AMFLAGS}を定義す
べきです.

@c When @code{aclocal -I m4} is run, it will build a @code{aclocal.m4}
@c that @code{m4_include}s any file from @file{m4/} that defines a
@c required macro.  Macros not found locally will still be searched in
@c system-wide directories, as explained in @ref{Macro search path}.
@c 
@code{aclocal -I m4}が実行されるとき,要求されているマクロが定義されて
いる@file{m4/}のあらゆるファイルを@code{m4_include}し,
@code{aclocal.m4}をビルドします.ローカルに見つからないマクロは,
@ref{Macro search path}で説明されているシステム全体のディレクトリで検
索されます.

@c Custom macros should be distributed for the same reason that
@c @file{configure.ac} is: so that other people have all the sources of
@c your package if they want to work on it.  Actually, this distribution
@c happens automatically because all @code{m4_include}d files are
@c distributed.
@c 
カスタムマクロは@file{configure.ac}と同じ理由で配布すべきです.パッケー
ジを動作させたい人は,そのすべてのファイルを持っているようにすべきです.
実際これは,すべての@code{m4_include}されるファイルが配布されるので,
自動的に配布されます.

@c However there is no consensus on the distribution of third-party
@c macros that your package may use.  Many libraries install their own
@c macro in the system-wide @command{aclocal} directory (@pxref{Extending
@c aclocal}).  For instance Guile ships with a file called
@c @file{guile.m4} that contains the macro @code{GUILE_FLAGS} which can
@c be used to define setup compiler and linker flags appropriate for
@c using Guile.  Using @code{GUILE_FLAGS} in @file{configure.ac} will
@c cause @command{aclocal} to copy @file{guile.m4} into
@c @file{aclocal.m4}, but as @file{guile.m4} is not part of the project,
@c it will not be distributed.  Technically, that means a user which
@c needs to rebuild @file{aclocal.m4} will have to install Guile first.
@c This is probably OK, if Guile already is a requirement to build the
@c package.  However, if Guile is only an optional feature, or if your
@c package might run on architectures where Guile cannot be installed,
@c this requirement will hinder development.  An easy solution is to copy
@c such third-party macros in your local @file{m4/} directory so they get
@c distributed.
@c 
しかし,パッケージで使用しているサードパーティーのマクロの配布には一致
している見解はありません.多くのライブラリは,独自のマクロをシステム全
体の@command{aclocal}ディレクトリ(@pxref{Extending aclocal})にインストー
ルします.例えば,Guileはコンパイラの設定とGuileを使用する際に適切なリ
ンカフラグ定義するために使用することが可能な,マクロ@code{GUILE_FLAGS} 
を含んでいる@file{guile.m4}と呼ばれるファイルを配布しています.
@file{configure.ac}で@code{GUILE_FLAGS}を使用することで,
@command{aclocal}は@file{guile.m4}を@file{aclocal.m4}にコピーしますが,
@file{guile.m4}はプロジェクトの一部ではないので,それは配布していませ
ん.技術的には,@file{aclocal.m4}をリビルドする必要があるユーザはGuile 
を最初にインストールする必要があることを意味します.Guileがパッケージ
のビルドで必要な場合,これはおそらく問題無いでしょう.しかし,Guileは
単なる追加機能だったり,パッケージをGuileがインストール不可能なマシン
で実行する可能性がある場合,この必要条件は開発の邪魔になります.簡単な
解決方法は,そのようなサードパーティーのマクロを,それらも配布されるよ
うに,ローカルな@file{m4/}ディレクトリにコピーすることです.

@node Future of aclocal
@c @section The Future of @command{aclocal}
@section @command{aclocal}の将来
@cindex aclocal's scheduled death

@c @command{aclocal} is expected to disappear.  This feature really
@c should not be offered by Automake.  Automake should focus on generating
@c @file{Makefile}s; dealing with M4 macros really is Autoconf's job.
@c That some people install Automake just to use @command{aclocal}, but
@c do not use @command{automake} otherwise is an indication of how that
@c feature is misplaced.
@c 
@command{aclocal}の消滅が予想されています.この機能はAutomakeで提供す
るものではありません.Automakeは@file{Makefile}の生成に焦点を絞るべき
です.M4マクロの処理は,本当はAutoconfの仕事でしょう.
@command{aclocal}を使用するためだけにAutomakeをインストールしていて,
それ以外での@command{automake}を使用しない人もいますが,それこそが,こ
の機能が場違いであることを示しています.

@c The new implementation will probably be done slightly differently.
@c For instance it could enforce the @file{m4/}-style layout discussed in
@c @ref{Local Macros}, and take care of copying (and even updating)
@c third-party macros from @file{/usr/share/aclocal/} into the local
@c @file{m4/} directory.
@c 
新たな実装は,若干違うものになる可能性があります.例えば,@ref{Local
Macros}で議論した@file{m4/}形式の配置を強制し,
@file{/usr/share/aclocal/}から持ってきたサードパーティーのマクロをこの
ディレクトリにコピー(そして更新)するようになるかもしれません.

@c We have no idea when and how this will happen.  This has been
@c discussed several times in the past, but someone still has to commit
@c itself to that non-trivial task.
@c 
我々には,これがどうすれば良いか分かりません.このことは,これまでに何
度も議論されてきましたが,誰かがそのような不明確な作業を自分に科さなけ
ればなりません.

@c From the user point of view, @command{aclocal}'s removal might turn
@c out to be painful.  There is a simple precaution that you may take to
@c make that switch more seamless: never call @command{aclocal} yourself.
@c Keep this guy under the exclusive control of @command{autoreconf} and
@c Automake's rebuild rules.  Hopefully you won't need to worry about
@c things breaking, when @command{aclocal} disappears, because everything
@c will have been taken care of.  If otherwise you used to call
@c @command{aclocal} directly yourself or from some script, you will
@c quickly notice the change.
@c 
ユーザの視点からは,@command{aclocal}の消滅は痛ましいものになり得ます.
がたがたしないように切替えるための予防策があります.それは自分で
@command{aclocal}を呼び出さないことです.こいつを@command{autoreconf} 
の制御下に追いやったり,Automakeのリビルドのルールにしたりしてください.
希望としては,@command{aclocal}が無くなったとき,すべての面倒が見られ
ていて,崩壊後に悩む必要が無いようにしたいことでしょう.それ以外で,直
接,またはスクリプトから@command{aclocal}を呼び出している場合,変更に
注意して下さい.

@c Many packages come with a script called @file{bootstrap.sh} or
@c @file{autogen.sh}, that will just call @command{aclocal},
@c @command{libtoolize}, @command{gettextize} or @command{autopoint},
@c @command{autoconf}, @command{autoheader}, and @command{automake} in
@c the right order.  Actually this is precisely what @command{autoreconf}
@c can do for you.  If your package has such a @file{bootstrap.sh} or
@c @file{autogen.sh} script, consider using @command{autoreconf}.  That
@c should simplify its logic a lot (less things to maintain, yum!), it's
@c even likely you will not need the script anymore, and more to the point
@c you will not call @command{aclocal} directly anymore.
@c 
@command{aclocal},@command{libtoolize},@command{gettextize}または
@command{autopoint},@command{autoconf},@command{autoheader},そして
@command{automake}を正しい順序で呼び出している,@file{bootstrap.sh}や
@file{autogen.sh}といったスクリプトが一緒になっているパッケージもたく
さんあります.実際,これは@command{autoreconf}でできることと全く同じで
す.@file{bootstrap.sh}や@file{autogen.sh}のようなスクリプトがパッケー
ジにある場合,@command{autoreconf}の使用を検討してみて下さい.それは論
理的にずいぶん簡単になり(管理には旨味はないけどね!),スクリプトはもは
や不要で,@command{aclocal}を直接呼び出す場所も無くなります.

@c For the time being, third-party packages should continue to install
@c public macros into @code{/usr/share/aclocal/}.  If @command{aclocal}
@c is replaced by another tool it might make sense to rename the
@c directory, but supporting @code{/usr/share/aclocal/} for backward
@c compatibility should be really easy provided all macros are properly
@c written (@pxref{Extending aclocal}).
@c 
しばらくは,サードパーティのパッケージはパブリックマクロを
@code{/usr/share/aclocal/}にインストールし続けるでしょう.
@command{aclocal}が別のツールに置き換えられる場合,ディレクトリ名を変
更することに意味がありますが,すべてのマクロの後方互換性をより容易に提
供するため,@code{/usr/share/aclocal/}をサポートし続けるように書かれる
ことになるでしょう(@pxref{Extending aclocal}).


@node Directories
@c @chapter Directories
@chapter ディレクトリ

@c For simple projects that distributes all files in the same directory
@c it is enough to have a single @file{Makefile.am} that builds
@c everything in place.
@c 
配布されるすべてのファイルが同じディレクトリにある単純なプロジェクトに
対して,すべてをその場でビルドする単一の@file{Makefile.am}があれば十分
です.

@c In larger projects it is common to organize files in different
@c directories, in a tree.  For instance one directory per program, per
@c library or per module.  The traditional approach is to build these
@c subdirectory recursively: each directory contains its @file{Makefile}
@c (generated from @file{Makefile.am}), and when @command{make} is run
@c from the top level directory it enters each subdirectory in turn to
@c build its contents.
@c 
大きなプロジェクトでは,ツリーの別々のディレクトリに体系化されたファイ
ルがあるのが一般的です.例えば,プログラムごと,ライブラリごと,そして
モジュールごと一つのディレクトリがあります.伝統的な手法は,これらのサ
ブディレクトリを再帰的にビルドしていました.それぞれのディレクトリには
(@file{Makefile.am}から生成された)@file{Makefile}が含まれており,
@command{make}をトップレベルのディレクトリで実行すると,それぞれのサブ
ディレクトリに移動し,順番にその内容をビルドしていきます.

@menu
* Subdirectories::              Building subdirectories recursively
* Conditional Subdirectories::  Conditionally not building directories
* Alternative::                 Subdirectories without recursion
* Subpackages::                 Nesting packages
@end menu

@node Subdirectories
@c @section Recursing subdirectories
@section サブディレクトリの再帰

@cindex SUBDIRS, explained

@c In packages with subdirectories, the top level @file{Makefile.am} must
@c tell Automake which subdirectories are to be built.  This is done via
@c the @code{SUBDIRS} variable.
@c 
サブディレクトリがあるパッケージでは,最上位の@file{Makefile.am}でビル
ドするサブディレクトリをAutomakeに伝える必要があります.これは
@code{SUBDIRS}変数によってなされます.
@vindex SUBDIRS

@c The @code{SUBDIRS} variable holds a list of subdirectories in which
@c building of various sorts can occur.  The rules for many targets
@c (e.g. @code{all}) in the generated @file{Makefile} will run commands
@c both locally and in all specified subdirectories.  Note that the
@c directories listed in @code{SUBDIRS} are not required to contain
@c @file{Makefile.am}s; only @file{Makefile}s (after configuration).
@c This allows inclusion of libraries from packages which do not use
@c Automake (such as @code{gettext}; see also @ref{Third-Party
@c Makefiles}).
@c 
@code{SUBDIRS}変数は,さまざまな種類のビルドが行われるサブディレクトリ
のリストを保持しています.生成されている@file{Makefile}内の多くのター
ゲットに対するルールは(例えば@code{all}),ローカルと指定されたすべての
サブディレクトリの両方で実行されます.@code{SUBDIRS}でリストアップされ
ているディレクトリには,@file{Makefile.am}を含んでいる必要がないことに
注意してください.(configure後の)@file{Makefile}だけが必要です.こうす
ることで,(@code{gettext}のようなもので,@ref{Third-Party Makefiles} 
も参照して下さい)Automakeを使用しないパッケージからライブラリを含める
ことが可能になります.

@c In packages that use subdirectories, the top-level @file{Makefile.am} is
@c often very short.  For instance, here is the @file{Makefile.am} from the
@c GNU Hello distribution:
@c 
サブディレクトリを使用しているパッケージでは,最上位の
@file{Makefile.am}は非常に短いことが多くなっています.例えば,GNU
Hello 配布物の@file{Makefile.am}は以下のようになっています.

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

@c When Automake invokes @code{make} in a subdirectory, it uses the value
@c of the @code{MAKE} variable.  It passes the value of the variable
@c @code{AM_MAKEFLAGS} to the @code{make} invocation; this can be set in
@c @file{Makefile.am} if there are flags you must always pass to
@c @code{make}.
@c 
Automakeが@code{make}をサブディレクトリで呼び出すとき,@code{MAKE}変数
の値を使用します.それは,変数@code{AM_MAKEFLAGS}の値を@code{make}の呼
び出しに渡します.これで,常に@code{make}に渡す必要があるフラグを
@file{Makefile.am}で設定することが可能になります.
@vindex MAKE
@vindex AM_MAKEFLAGS

@c The directories mentioned in @code{SUBDIRS} are usually direct
@c children of the current directory, each subdirectory containing its
@c own @file{Makefile.am} with a @code{SUBDIRS} pointing to deeper
@c subdirectories.  Automake can be used to construct packages of
@c arbitrary depth this way.
@c 
@code{SUBDIRS}で記述されているディレクトリは,通常,現在のディレクトリ
の直接の子ディレクトリになっていて,それぞれのサブディレクトリには,そ
れより不快サブディレクトリを示す@code{SUBDIRS}を示している,独自の
@file{Makefile.am}が含まれています.この方法で任意の深さのパッケージ構
成で,Automakeを使用することがが可能になります.

@c By default, Automake generates @file{Makefiles} which work depth-first
@c in postfix order: the subdirectories are built before the current
@c directory.  However, it is possible to change this ordering.  You can
@c do this by putting @samp{.} into @code{SUBDIRS}.  For instance,
@c putting @samp{.}  first will cause a @samp{prefix} ordering of
@c directories.
@c 
デフォルトで,Automakeはpostfixの順序での最初の深さで動作する
@file{Makefile}を生成します.サブディレクトリはカレントディレクトリの
前にビルドされます.しかし,この順序を変更することは可能です.
@code{SUBDIRS}に@samp{.}を書くことでこうすることが可能です.例えば,
@samp{.}を最初に書くことで,ディレクトリの@samp{prefix}の順序になりま
す.

@c Using
@c 
以下を使用します.

@example
SUBDIRS = lib src . test
@end example

@noindent
@c will cause @file{lib/} to be built before @file{src/}, then the
@c current directory will be built, finally the @file{test/} directory
@c will be built.  It is customary to arrange test directories to be
@c built after everything else since they are meant to test what have
@c been constructed.
@c 
これで@file{lib/}が@file{src/}の前にビルドされ,そしてカレントディレク
トリがビルドされ,最後に@file{test/}ディレクトリがビルドされるでしょう.
構成されたものをテストするので,テストディレクトリを他のすべての後にビ
ルドするように手配するのは一般的です.

@c All @samp{clean} rules are run in reverse order of build rules.
@c 
すべての@samp{clean}ルールは,ビルドルールの逆の順序で実行されます.

@node Conditional Subdirectories
@c @section Conditional Subdirectories
@section サブディレクトリの条件
@cindex Subdirectories, building conditionally
@cindex Conditional subdirectories
@cindex @code{SUBDIRS}, conditional
@cindex Conditional @code{SUBDIRS}

@c It is possible to define the @code{SUBDIRS} variable conditionally if,
@c like in the case of GNU @code{Inetutils}, you want to only build a
@c subset of the entire package.
@c 
GNU @code{Inetutils}のように,パッケージ全体のサブセットをビルドしたい
だけの場合,@code{SUBDIRS}変数を条件的に定義することがが可能です.

@c To illustrate how this works, let's assume we have two directories
@c @file{src/} and @file{opt/}.  @file{src/} should always be built, but we
@c want to decide in @code{./configure} whether @file{opt/} will be built
@c or not.  (For this example we will assume that @file{opt/} should be
@c built when the variable @code{$want_opt} was set to @code{yes}.)
@c 
これがどのように動作するかを説明するため,二つのディレクトリ
@file{src/} と@file{opt/}があると仮定しましょう.@file{src/}は常にビル
ドされますが,@file{opt/}は@code{./configure}でビルドするかどうかを決
定したいと思います.(この例では,変数@code{$want_opt}が@code{yes}に設
定されているとき@file{opt/}をビルドすると仮定します.)

@c Running @code{make} should thus recurse into @file{src/} always, and
@c then maybe in @file{opt/}.
@c 
@code{make}と実行することで,@file{src/}は常に再帰され,@file{opt/}も
そうなるかもしれません.

@c However @code{make dist} should always recurse into both @file{src/}
@c and @file{opt/}.  Because @file{opt/} should be distributed even if it
@c is not needed in the current configuration. This means
@c @file{opt/Makefile} should be created @emph{unconditionally}.
@c 
しかし,@code{make dist}では常に@file{src/}と@file{opt/}の両方を再帰す
べきです.つまり,現在のconfigureでは不要な場合でも,@file{opt/}は配布
されるべきです.これは,@file{opt/Makefile}は@emph{条件に依存せず}作成
されるべきだということを意味します.

@c There are two ways to setup a project like this.  You can use Automake
@c conditionals (@pxref{Conditionals}) or use Autoconf @code{AC_SUBST}
@c variables (@pxref{Setting Output Variables, , Setting Output
@c Variables, autoconf, The Autoconf Manual}).  Using Automake
@c conditionals is the preferred solution.  Before we illustrate these
@c two possibility, let's introduce @code{DIST_SUBDIRS}.
@c 
このようにプロジェクトを設定する方法は二つあります.Automakeの条件式
(@pxref{Conditionals})を使用したり,Autoconfの@code{AC_SUBST}マクロ
(@pxref{Setting Output Variables, , Setting Output Variables,
autoconf, The Autoconf Manual})を使用したりすることが可能です.
Automakeの条件式の使用は,より好まれる解となります.これら二つの可能性
を示す前に,@code{DIST_SUBDIRS}を紹介しましょう.

@c @subsection @code{SUBDIRS} vs. @code{DIST_SUBDIRS}
@subsection @code{SUBDIRS}対@code{DIST_SUBDIRS}
@cindex @code{DIST_SUBDIRS}, explained

@c Automake considers two sets of directories, defined by the variables
@c @code{SUBDIRS} and @code{DIST_SUBDIRS}.
@c 
Automakeは,@code{SUBDIRS}と@code{DIST_SUBDIRS}で定義される,二つのディ
レクトリ・セットを考慮します.

@c @code{SUBDIRS} contains the subdirectories of the current directory
@c that must be built (@pxref{Subdirectories}).  It must be defined
@c manually; Automake will never guess a directory is to be built.  As we
@c will see in the next two sections, it is possible to define it
@c conditionally so that some directory will be omitted from the build.
@c 
@code{SUBDIRS}は,ビルドする必要があるカレント・ディレクトリのサブディ
レクトリを含んでいます(@pxref{Subdirectories}).それは手動で定義する必
要があります.Automakeは,ビルドするディレクトリかどうかを判定すること
はありません.以下の二つのセクションで分かるように,ビルドするディレク
トリからいくつかのディレクトリを削除する条件を定義することが可能です.

@c @code{DIST_SUBDIRS} is used in rules that need to recurse in all
@c directories, even those which have been conditionally left out of the
@c build.  Recall our example where we may not want to build subdirectory
@c @file{opt/}, but yet we want to distribute it?  This is where
@c @code{DIST_SUBDIRS} come into play: @code{opt} may not appear in
@c @code{SUBDIRS}, but it must appear in @code{DIST_SUBDIRS}.
@c 
@code{DIST_SUBDIRS}はすべてのディレクトリを再帰する必要があるルールで
使用され,ビルドされる条件から外れていても使用されます.サブディレクト
リ@file{opt/}はビルドしないのに,それを配布したいという例を思い出しま
したか?これは@code{DIST_SUBDIRS}で行ないます.@code{opt}は
@code{SUBDIRS}にはありませんが,@code{DIST_SUBDIRS}には存在する必要が
あります.

@c Precisely, @code{DIST_SUBDIRS} is used by @code{make dist}, @code{make
@c distclean}, and @code{make maintainer-clean}.  All other recursive
@c rules use @code{SUBDIRS}.
@c 
厳密にいうと,@code{DIST_SUBDIRS}は@code{make dist},@code{make
distclean},そして@code{make maintainer-clean}で使用されます.それ以外
の再帰的なルールでは@code{SUBDIRS}が使用されます.

@c If @code{SUBDIRS} is defined conditionally using Automake
@c conditionals, Automake will define @code{DIST_SUBDIRS} automatically
@c from the possibles values of @code{SUBDIRS} in all conditions.
@c 
@code{SUBDIRS}がAutomakeの条件文を使用し条件的に定義される場合,
Automakeは,すべての条件で@code{SUBDIRS}がとり得る値で,
@code{DIST_SUBDIRS}を自動的に定義します.

@c If @code{SUBDIRS} contains @code{AC_SUBST} variables,
@c @code{DIST_SUBDIRS} will not be defined correctly because Automake
@c does not know the possible values of these variables.  In this case
@c @code{DIST_SUBDIRS} needs to be defined manually.
@c 
@code{SUBDIRS}が@code{AC_SUBST}変数を含む場合,Automakeはこれらの変数
がとり得る値が分からないので,@code{DIST_SUBDIRS}は正確に定義できませ
ん.この状況では,@code{DIST_SUBDIRS} を手動で定義する必要があります.


@c @subsection Conditional subdirectories with @code{AM_CONDITIONAL}
@subsection @code{AM_CONDITIONAL}を用いた条件付サブディレクトリ
@cindex @code{SUBDIRS} and @code{AM_CONDITIONAL}
@cindex @code{AM_CONDITIONAL} and @code{SUBDIRS}

@c The test case for the setup described here is
@c     test/subdircond2.test
@c Try to keep it in sync.

@c @file{configure} should output the @file{Makefile} for each directory
@c and define a condition into which @file{opt/} should be built.
@c 
@file{configure}でそれぞれのディレクトリの@file{Makefile}を出力し,
@file{opt/}をビルドするかどうかの条件を定義すべきです.

@example
@dots{}
AM_CONDITIONAL([COND_OPT], [test "$want_opt" = yes])
AC_CONFIG_FILES([Makefile src/Makefile opt/Makefile])
@dots{}
@end example

@c Then @code{SUBDIRS} can be defined in the top-level @file{Makefile.am}
@c as follows.
@c 
@code{SUBDIRS}は,最上位の@file{Makefile.am}で,以下のように定義するこ
とが可能です.

@example
if COND_OPT
  MAYBE_OPT = opt
endif
SUBDIRS = src $(MAYBE_OPT)
@end example

@c As you can see, running @code{make} will rightly recurse into
@c @file{src/} and maybe @file{opt/}.
@c 
御覧のように,@code{make}を実行することで,@file{src/}と,おそらく
@file{opt/}に再帰していくでしょう.

@vindex DIST_SUBDIRS
@c As you can't see, running @code{make dist} will recurse into both
@c @file{src/} and @file{opt/} directories because @code{make dist}, unlike
@c @code{make all}, doesn't use the @code{SUBDIRS} variable.  It uses the
@c @code{DIST_SUBDIRS} variable.
@c 
見ることはできませんが,@code{make dist}は@code{make all}とは異なり,
@code{SUBDIRS}変数を使用しないので,@code{make dist}を実行することで,
@file{src/}と@file{opt/}の両方に再帰的に行ないます.それは
@code{DIST_SUBDIRS}変数を使用します.

@c In this case Automake will define @code{DIST_SUBDIRS = src opt}
@c automatically because it knows that @code{MAYBE_OPT} can contain
@c @code{opt} in some condition.
@c 
この場合,Automakeは@code{MAYBE_OPT}が条件によっては@code{opt}を含むこ
とを知っているので,@code{DIST_SUBDIRS = src opt}を自動的に定義します.

@c @subsection Conditional Subdirectories with @code{AC_SUBST}
@subsection @code{AC_SUBST}を用いたサブディレクトリの条件式
@cindex @code{SUBDIRS} and @code{AC_SUBST}
@cindex @code{AC_SUBST} and @code{SUBDIRS}

@c The test case for the setup described here is
@c     test/subdircond3.test
@c Try to keep it in sync.

@c Another possibility is to define @code{MAYBE_OPT} from
@c @file{./configure} using @code{AC_SUBST}:
@c 
もう一つの可能な方法は,@code{AC_SUBST}を使用して,@file{./configure}
で@code{MAYBE_OPT}を定義することです.

@example
@dots{}
if test "$want_opt" = yes; then
  MAYBE_OPT=opt
else
  MAYBE_OPT=
fi
AC_SUBST([MAYBE_OPT])
AC_CONFIG_FILES([Makefile src/Makefile opt/Makefile])
@dots{}
@end example

@c In this case the top-level @file{Makefile.am} should look as follows.
@c 
この状況では,最上位の@file{Makefile.am}は以下のようになるでしょう.

@example
SUBDIRS = src $(MAYBE_OPT)
DIST_SUBDIRS = src opt
@end example

@c The drawback is that since Automake cannot guess what the possible
@c values of @code{MAYBE_OPT} are, it is necessary to define
@c @code{DIST_SUBDIRS}.
@c 
欠点は,Automakeが@code{MAYBE_OPT}の変数が何かを推測することが不可能な
ので,@code{DIST_SUBDIRS}に定義する必要があるということです.

@c @subsection Non-configured Subdirectories
@subsection コンフィグレーションされないサブディレクトリ

@c The semantic of @code{DIST_SUBDIRS} is often misunderstood by some
@c users that try to @emph{configure and build} subdirectories
@c conditionally.  Here by configuring we mean creating the
@c @file{Makefile} (it might also involve running a nested
@c @command{configure} script: this is a costly operation that explains
@c why people want to do it conditionally, but only the @file{Makefile}
@c is relevant to the discussion).
@c 
@code{DIST_SUBDIRS}の意味は,サブディレクトリを条件的に@emph{コンフィ
グレーションしビルド}しようとするユーザに誤解されていることが多くなっ
ています.ここでのコンフィグレーションとは,@file{Makefile}の作成を意
味します(入れ子状の@command{configure}スクリプトの呼び出しの可能性もあ
ります.これはコストのかかる処理で,条件的にしたい言い訳にしますが,
@file{Makefile}に関することだけを議論します).

@c The above examples all assume that every @file{Makefile} is created,
@c even in directories that are not going to be built.  The simple reason
@c is that we want @code{make dist} to distribute even the directories
@c that are not being built (e.g. platform-dependent code), hence
@c @file{make dist} must recurse into the subdirectory, hence this
@c directory must be configured and appear in @code{DIST_SUBDIRS}.
@c 
上記の例ではすべて,ビルドされないディレクトリを含めて,全部の
@file{Makefile}の作成を仮定しています.単純な理由として,@code{make
dist}でビルドされないディレクトリも配布したいことがあり(例えば,プラッ
トフォーム依存のコード),このため@file{make dist}でサブディレクトリを
再帰的にする必要があり,更にこのディレクトリをコンフィグレーションし
@code{DIST_SUBDIRS}に存在させる必要があります.

@c Building packages that do not configure every subdirectory is a tricky
@c business, and we do not recommend it to the novice as it is easy to
@c produce an incomplete tarball by mistake.  We will not discuss this
@c topic in depth here, yet for the adventurous there are a few rules to
@c remember.
@c 
すべてのサブディレクトリをコンフィグレーションするわけではないパッケー
ジのビルドはトリッキーな作業になり,間違って不完全なtarballを生成しが
ちなので,初心者にはお勧めしません.我々はこのトピックをここでは深く議
論しませんが,ちょっと危険なので,いくつかルールがあることを覚えておい
て下さい.

@cartouche
@itemize
@c @item @code{SUBDIRS} should always be a subset of @code{DIST_SUBDIRS}.
@item @code{SUBDIRS}は常に@code{DIST_SUBDIRS}のサブセット(下位集合)にすべきです.

@c It makes little sense to have a directory in @code{SUBDIRS} that
@c is not in @code{DIST_SUBDIRS}.  Think of the former as a way to tell
@c which directories listed in the latter should be built.
@c 
@code{DIST_SUBDIRS}には無いディレクトリを@code{SUBDIRS}に書くことには
ちょっとだけ意味があります.前者はディレクトリのリストを伝える方法で,
後者はビルドすべきものです.

@c @item Any directory listed in @code{DIST_SUBDIRS} and @code{SUBDIRS} must be configured.
@item @code{DIST_SUBDIRS}と@code{SUBDIRS}にリストアップされるディレクトリは,すべてコンフィグレーションすべきです.

@c I.e., the @file{Makefile} must exists or the recursive @code{make}
@c rules will not be able to process the directory.
@c 
すなわち,@file{Makefile}が存在する必要があり,そうしなければ,再帰的
な@code{make}ルールでディレクトリを処理することができません.

@c @item Any configured directory must be listed in @code{DIST_SUBDIRS}.
@item コンフィグレーションされるディレクトリはすべて@code{DIST_SUBDIRS}にリストアップする必要があります.

@c So that the cleaning rule remove the generated @file{Makefile}s.
@c It would be correct to see @code{DIST_SUBDIRS} as a variable that
@c lists all the directories that have been configured.
@c 
cleanルールで生成された@file{Makefile}を削除するようにするためです.
@code{DIST_SUBDIRS}が変数として,コンフィグレーションされるすべてのディ
レクトリをリストアップしていることを確認するのが王道です.

@end itemize
@end cartouche

@c In order to prevent recursion in some non-configured directory you
@c must therefore ensure that this directory do not appear in
@c @code{DIST_SUBDIRS} (and @code{SUBDIRS}).  For instance if you define
@c @code{SUBDIRS} conditionally using @code{AC_SUBST} and do not define
@c @code{DIST_SUBDIRS} explicitly, it will be default to
@c @code{$(SUBDIRS)}; another possibility is to force @code{DIST_SUBDIRS
@c = $(SUBDIRS)}.
@c 
コンフィグレーションされないディレクトリを再帰するのを避けるため,その
ディレクトリが確実に@code{DIST_SUBDIRS}(と@code{SUBDIRS})に存在しない
ことを確かめる必要があります.例えば,@code{AC_SUBST}を使用して
@code{SUBDIRS}を条件的に定義していて,@code{DIST_SUBDIRS}が明示的に定
義されていない場合,それはデフォルトで@code{$(SUBDIRS)}になります.も
う一つの可能性として,@code{DIST_SUBDIRS = $(SUBDIRS)}を強制します.


@node Alternative
@c @section An Alternative Approach to Subdirectories
@section サブディレクトリに代わるアプローチ

@c If you've ever read Peter Miller's excellent paper,
@c @uref{http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html,
@c Recursive Make Considered Harmful}, the preceding sections on the use of
@c subdirectories will probably come as unwelcome advice.  For those who
@c haven't read the paper, Miller's main thesis is that recursive
@c @code{make} invocations are both slow and error-prone.
@c 
Peter Millerの優れた論文をすでに読んでいる場合
@uref{http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html,
Recursive Make Considered Harmful},サブディレクトリを使用する前のセク
ションは,おそらくありがたくない助言になるでしょう.論文を読んでいない
人のために,Millerの主題は,再帰的な@code{make}の呼び出しは,遅くてエ
ラーを発生しやすいということです.

@c Automake provides sufficient cross-directory support @footnote{We
@c believe.  This work is new and there are probably warts.
@c @xref{Introduction}, for information on reporting bugs.} to enable you
@c to write a single @file{Makefile.am} for a complex multi-directory
@c package.
@c 
複雑な複数のディレクトリがあるパッケージに対して,単一の
@file{Makefile.am}だけを書くことを可能にする,ディレクトリを跨るための
優れたサポート@footnote{我々は信じています.この動作は新しく,問題があ
る可能性があります.バグレポートの情報は,@xref{Introduction}.}を,
Automake は提供しています.


@c By default an installable file specified in a subdirectory will have its
@c directory name stripped before installation.  For instance, in this
@c example, the header file will be installed as
@c @file{$(includedir)/stdio.h}:
@c 
デフォルトで,サブディレクトリで指定されているインストール可能なファイ
ルは,インストールする前にそのディレクトリ名が切り取られています.例え
ば以下の例では,ヘッダファイルが@file{$(includedir)/stdio.h}にインストー
ルされるでしょう.

@example
include_HEADERS = inc/stdio.h
@end example

@cindex nobase_
@cindex Path stripping, avoiding
@cindex Avoiding path stripping

@c However, the @samp{nobase_} prefix can be used to circumvent this path
@c stripping.  In this example, the header file will be installed as
@c @file{$(includedir)/sys/types.h}:
@c 
しかし,@samp{nobase_}を前置することで,このパスを切り取りを回避するこ
とが可能になります.以下の例では,ヘッダファイルは
@file{$(includedir)/sys/types.h}にインストールされるでしょう.

@example
nobase_include_HEADERS = sys/types.h
@end example

@cindex nobase_ and dist_ or nodist_
@cindex dist_ and nobase_
@cindex nodist_ and nobase_

@c @samp{nobase_} should be specified first when used in conjunction with
@c either @samp{dist_} or @samp{nodist_} (@pxref{Dist}).  For instance:
@c 
@samp{nobase_}は,@samp{dist_}や@samp{nodist_}(@pxref{Dist})のいずれか
と組合わせて使用するとき,最初に指定するべきです.例えば以下のようにし
ます.

@example
nobase_dist_pkgdata_DATA = images/vortex.pgm
@end example


@node Subpackages
@c @section Nesting Packages
@section 入れ子状のパッケージ
@cindex Nesting packages
@cindex Subpackages
@cvindex AC_CONFIG_SUBDIRS
@cvindex AC_CONFIG_AUX_DIR


@c In the GNU Build System, packages can be nested to arbitrary depth.
@c This means that a package can embedded other packages with their own
@c @file{configure}, @file{Makefile}s, etc.
@c 
GNUビルド・システムでは,パッケージを任意の深さに入れ子状にすることが
可能です.これは,独自の@file{configure},@file{Makefile}などがある他
のパッケージを埋め込んだパッケージが可能になることを意味します.

@c These other packages should just appear as subdirectories of their
@c parent package.  They must be listed in @code{SUBDIRS} like other
@c ordinary directories.  However the subpackage's @file{Makefile}s
@c should be output by its own @file{configure} script, not by the
@c parent's @file{configure}.  This is achieved using the
@c @code{AC_CONFIG_SUBDIRS} Autoconf macro (@pxref{Subdirectories,
@c AC_CONFIG_SUBDIRS, Configuring Other Packages in Subdirectories,
@c autoconf, The Autoconf Manual}).
@c 
これらのその他のパッケージは,親パッケージのサブディレクトリに存在する
ようにすべきです.それらは,他の普通のディレクトリと同様に
@code{SUBDIRS}にリストアップする必要があります.しかし,サブパッケージ
の@file{Makefile}は,親の@file{configure}ではなく,独自の
@file{configure}スクリプトで出力するようにすべきです.これはAutoconfマ
クロの@code{AC_CONFIG_SUBDIRS}を使用して達成します
(@pxref{Subdirectories, AC_CONFIG_SUBDIRS, Configuring Other Packages
in Subdirectories, autoconf, The Autoconf Manual}).

@c Here is an example package for an @code{arm} program that links with
@c an @code{hand} library that is a nested package in subdirectory
@c @file{hand/}.
@c 
サブディレクトリの@file{hand/}にある入れ子状のパッケージ@code{hand}ラ
イブラリとリンクする,@code{arm}プログラムのパッケージ例は,以下のよう
になります.

@c @code{arm}'s @file{configure.ac}:
@c 
@code{arm}の@file{configure.ac}です.

@example
AC_INIT([arm], [1.0])
AC_CONFIG_AUX_DIR([.])
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
# Call hand's ./configure script recursively.
AC_CONFIG_SUBDIRS([hand])
AC_OUTPUT
@end example

@c @code{arm}'s @file{Makefile.am}:
@c 
@code{arm}の@file{Makefile.am}です.

@example
# Build the library in the hand subdirectory first.
SUBDIRS = hand

# Include hand's header when compiling this directory.
AM_CPPFLAGS = -I$(srcdir)/hand

bin_PROGRAMS = arm
arm_SOURCES = arm.c
# link with the hand library.
arm_LDADD = hand/libhand.a
@end example

@c Now here is @code{hand}'s @file{hand/configure.ac}:
@c 
さて,@code{hand}の@file{hand/configure.ac}です.

@example
AC_INIT([hand], [1.2])
AC_CONFIG_AUX_DIR([.])
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_PROG_RANLIB
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
@end example

@noindent
@c and its @file{hand/Makefile.am}:
@c 
そしてその@file{hand/Makefile.am}です.

@example
lib_LIBRARIES = libhand.a
libhand_a_SOURCES = hand.c
@end example

@c When @code{make dist} is run from the top-level directory it will
@c create an archive @file{arm-1.0.tar.gz} that contains the @code{arm}
@c code as well as the @file{hand} subdirectory.  This package can be
@c built and installed like any ordinary package, with the usual
@c @code{./configure && make && make install} sequence (the @code{hand}
@c subpackage will be built and installed by the process).
@c 
@code{make dist}がトップレベルのディレクトリで実行されるとき,
@file{hand}サブディレクトリだけでなく,@code{arm}コードも含むアーカイ
ブ@file{arm-1.0.tar.gz}を作成します.このパッケージは,通常のパッケー
ジと同じように,いつもの@code{./configure && make && make install}でビ
ルドしインストールすることが可能です(@code{hand}サブパッケージは,処理
中にビルドとインストールがなされます.).

@c When @code{make dist} is run from the hand directory, it will create a
@c self-contained @file{hand-1.2.tar.gz} archive.  So although it appears
@c to be embedded in another package, it can still be used separately.
@c 
@code{make dist}が@code{hand}ディレクトリで実行されるとき,それ自身が
含まれている@file{hand-1.2.tar.gz}アーカイブを作成します.他のパッケー
ジに埋め込まれているのですが,別々に使用することも可能です.

@c The purpose of the @code{AC_CONFIG_AUX_DIR([.])} instruction is to
@c force Automake and Autoconf into search auxiliary script in the
@c current directory.  For instance this means that there will be two
@c copies of @file{install-sh}: one in the top-level of the @code{arm}
@c package, and another one in the @file{hand/} subdirectory for the
@c @code{hand} package.
@c 
@code{AC_CONFIG_AUX_DIR([.])}機能の目的は,AutomakeとAutoconfに追加ス
クリプトをカレントディレクトリで探すように強制することです.例えば,二
つの@file{install-sh}のコピーがあって,一つはトップレベルの@code{arm} 
パッケージ,もう一つは@code{hand}パッケージの@file{hand/}サブディレク
トリにあるということを意味します.

@c The historical default is to search these auxiliary scripts in the
@c immediate parent and grand-parent directories.  So if the
@c @code{AC_CONFIG_AUX_DIR([.])} line was removed from
@c @file{hand/configure.ac}, that subpackage would share the auxiliary
@c script of the @code{arm} package.  This may looks like a gain in size
@c (a few kilobytes), but it is actually a loss of modularity as the
@c @code{hand} subpackage is no longer self-contained (@code{make dist}
@c in the subdirectory will not work anymore).
@c 
歴史的なデフォルトは,これらの追加スクリプトを直接の親と更にその親のディ
レクトリで探します.そのため,@code{AC_CONFIG_AUX_DIR([.])}行が
@file{hand/configure.ac}からなくなると,サブパッケージは@code{arm}パッ
ケージの追加スクリプトを共有します.これは若干サイズが大きくなる(数Kバ
イト)ように見えますが,@code{hand}サブパッケージのモジュール性が実際に
なくなり,自身には含まれないことになってしまいます(サブディレクトリで
@code{make dist}しても動作しません).

@c Packages that do not use Automake need more work to be integrated this
@c way.  @xref{Third-Party Makefiles}.
@c 
Automakeを使用しないパッケージは,この方法で統合するために,さらなる作
業が必要です@xref{Third-Party Makefiles}.

@node Programs
@c @chapter Building Programs and Libraries
@chapter プログラムとライブラリのビルド

@c A large part of Automake's functionality is dedicated to making it easy
@c to build programs and libraries.
@c 
Automakeの機能の大半は,プログラムとライブラリのビルドを容易にすること
に費やされています.

@menu
* A Program::                   Building a program
* A Library::                   Building a library
* A Shared Library::            Building a Libtool library
* Program and Library Variables::  Variables controlling program and
                                library builds
* Default _SOURCES::            Default source files
* LIBOBJS::                     Special handling for LIBOBJS and ALLOCA
* Program variables::           Variables used when building a program
* Yacc and Lex::                Yacc and Lex support
* C++ Support::                 Compiling C++ sources
* Assembly Support::            Compiling assembly sources
* Fortran 77 Support::          Compiling Fortran 77 sources
* Fortran 9x Support::          Compiling Fortran 9x sources
* Java Support::                Compiling Java sources
* Support for Other Languages::  Compiling other languages
* ANSI::                        Automatic de-ANSI-fication
* Dependencies::                Automatic dependency tracking
* EXEEXT::                      Support for executable extensions
@end menu


@node A Program
@c @section Building a program
@section プログラムのビルド

@c In order to build a program, you need to tell Automake which sources
@c are part of it, and which libraries it should be linked with.
@c 
プログラムをビルドするために,その一部となるソースとリンクされるライブ
ラリをAutomakeに伝える必要があります.

@c This section also covers conditional compilation of sources or
@c programs.  Most of the comments about these also apply to libraries
@c (@pxref{A Library}) and libtool libraries (@pxref{A Shared Library}).
@c 
このセクションは,ソースやプログラムの条件付きコンパイルもカバーしてい
ます.これらのコメントのほとんどは,ライブラリ(@pxref{A Library})と
libtoolライブラリ(@pxref{A Shared Library})に適用されます.

@menu
* Program Sources::             Defining program sources
* Linking::                     Linking with libraries or extra objects
* Conditional Sources::         Handling conditional sources
* Conditional Programs::        Building program conditionally
@end menu

@node Program Sources
@c @subsection Defining program sources
@subsection プログラムソースの定義

@cindex PROGRAMS, bindir
@vindex bin_PROGRAMS
@vindex sbin_PROGRAMS
@vindex libexec_PROGRAMS
@vindex pkglib_PROGRAMS
@vindex noinst_PROGRAMS
@vindex check_PROGRAMS

@c In a directory containing source that gets built into a program (as
@c opposed to a library or a script), the @samp{PROGRAMS} primary is used.
@c Programs can be installed in @code{bindir}, @code{sbindir},
@c @code{libexecdir}, @code{pkglibdir}, or not at all (@samp{noinst}).
@c They can also be built only for @code{make check}, in which case the
@c prefix is @samp{check}.
@c 
(ライブラリやスクリプトと比べて)プログラムにビルドされるソースを含んで
いるディレクトリには,@samp{PROGRAMS}プライマリが使用されます.プログ
ラムを,@code{bindir},@code{sbindir},@code{libexecdir},
@code{pkglibdir}にインストールしたり,または全くインストールしない
(@code{noinst})ことが可能です.@code{make check}に対してのみビルドさせ
ることも可能で,そのときは接頭辞は@samp{check}になります.

@c For instance:
@c 
例えば以下のようにします.

@example
bin_PROGRAMS = hello
@end example

@c In this simple case, the resulting @file{Makefile.in} will contain code
@c to generate a program named @code{hello}.
@c 
この単純な状況では,結果として生成される@file{Makefile.in}に,
@code{hello}という名前のプログラムを生成するコードが含まれるでしょう.

@c Associated with each program are several assisting variables which are
@c named after the program.  These variables are all optional, and have
@c reasonable defaults.  Each variable, its use, and default is spelled out
@c below; we use the ``hello'' example throughout.
@c 
それぞれのプログラムに関連して,プログラムの後に命名される補助変数もあ
ります.これらの変数はすべてオプションで,妥当なデフォルト値を持ちます.
それぞれの変数,その使用,そしてデフォルトについては以下で記述します.
我々は,``hello''の例を終始使用します.

@c The variable @code{hello_SOURCES} is used to specify which source files
@c get built into an executable:
@c 
変数@code{hello_SOURCES}は,実行形式にビルドされるソースファイルを指定
するために使用されます.

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

@c This causes each mentioned @samp{.c} file to be compiled into the
@c corresponding @samp{.o}.  Then all are linked to produce @file{hello}.
@c 
これにより,上記のそれぞれの@samp{.c}ファイルを,対応する@samp{.o}にコ
ンパイルします.そして,すべては@file{hello}を生成するためにリンクされ
ます.

@cindex _SOURCES primary, defined
@cindex SOURCES primary, defined
@cindex Primary variable, SOURCES

@c If @samp{hello_SOURCES} is not specified, then it defaults to the single
@c file @file{hello.c} (@pxref{Default _SOURCES}).
@c 
@samp{hello_SOURCES}が指定されていない場合,そのデフォルトは一つのファ
イル@file{hello.c}になります(@pxref{Default _SOURCES}).
@vindex _SOURCES
@vindex SOURCES

@c Multiple programs can be built in a single directory.  Multiple programs
@c can share a single source file, which must be listed in each
@c @samp{_SOURCES} definition.
@c 
複数のプログラムを一つのディレクトリでビルドすることが可能です.複数の
プログラムで単一のソースファイルを共有することが可能で,それぞれの
@samp{_SOURCES}定義でリストアップする必要があります.

@cindex Header files in _SOURCES
@cindex _SOURCES and header files

@c Header files listed in a @samp{_SOURCES} definition will be included in
@c the distribution but otherwise ignored.  In case it isn't obvious, you
@c should not include the header file generated by @file{configure} in a
@c @samp{_SOURCES} variable; this file should not be distributed.  Lex
@c (@samp{.l}) and Yacc (@samp{.y}) files can also be listed; see @ref{Yacc
@c and Lex}.
@c 
@samp{_SOURCES}定義にリストアップされているヘッダファイルは配布物に含
まれますが,それ以外のものは無視されます.明らかではないときは,
@file{configure}で生成されるヘッダファイルを@samp{_SOURCES}変数に含め
るべきではありません.このファイルは配布すべきではありません.
Lex(@samp{.l})とYacc(@samp{.y})のファイルもリストアップすることが可能
です.@ref{Yacc and Lex}を参照して下さい.


@node Linking
@c @subsection Linking the program
@subsection プログラムのリンク

@c If you need to link against libraries that are not found by
@c @code{configure}, you can use @code{LDADD} to do so.  This variable is
@c used to specify additional objects or libraries to link with; it is
@c inappropriate for specifying specific linker flags, you should use
@c @code{AM_LDFLAGS} for this purpose.
@c 
@code{configure}で見つからないライブラリに対してリンクする必要がある場
合,そうするために@code{LDADD}を使用することが可能です.この変数は,リ
ンクする追加のオブジェクトやライブラリを指定するために使用されます.そ
れは,特定のリンカフラグを指定するには不適切で,この目的では
@code{AM_LDFLAGS}を使用すべきです.
@vindex LDADD
@vindex AM_LDFLAGS

@cindex prog_LDADD, defined

@c Sometimes, multiple programs are built in one directory but do not share
@c the same link-time requirements.  In this case, you can use the
@c @samp{@var{prog}_LDADD} variable (where @var{prog} is the name of the
@c program as it appears in some @samp{_PROGRAMS} variable, and usually
@c written in lowercase) to override the global @code{LDADD}.  If this
@c variable exists for a given program, then that program is not linked
@c using @code{LDADD}.
@c 
複数のプログラムが一つのディレクトリでビルドされていても,リンク時に同
じ条件を共有しないときもあります.この場合は,グローバルな@code{LDADD} 
に優先させるため,@samp{@var{prog}_LDADD}変数(ここでの@var{prog}はプロ
グラムの名前で,それは@samp{_PROGRAMS}変数にあって,通常は小文字で書か
れています)を使用することが可能です.この変数が所定のプログラムに対し
て存在する場合,そのプログラムは@code{LDADD}を使用してリンクされません.
@vindex _LDADD

@c For instance, in GNU cpio, @code{pax}, @code{cpio} and @code{mt} are
@c linked against the library @file{libcpio.a}.  However, @code{rmt} is
@c built in the same directory, and has no such link requirement.  Also,
@c @code{mt} and @code{rmt} are only built on certain architectures.  Here
@c is what cpio's @file{src/Makefile.am} looks like (abridged):
@c 
例えば,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

@cindex _LDFLAGS, defined

@c @samp{@var{prog}_LDADD} is inappropriate for passing program-specific
@c linker flags (except for @samp{-l}, @samp{-L}, @samp{-dlopen} and
@c @samp{-dlpreopen}).  So, use the @samp{@var{prog}_LDFLAGS} variable for
@c this purpose.
@c 
@samp{@var{prog}_LDADD}でプログラム独自のリンカフラグ(@samp{-l},
@samp{-L},@samp{-dlopen}そして@samp{-dlpreopen}を除く)を渡すことは不
適当です.そのため,この目的に対しては@samp{@var{prog}_LDFLAGS}変数を
使用してください.
@vindex _LDFLAGS

@cindex _DEPENDENCIES, defined

@c It is also occasionally useful to have a program depend on some other
@c target which is not actually part of that program.  This can be done
@c using the @samp{@var{prog}_DEPENDENCIES} variable.  Each program depends
@c on the contents of such a variable, but no further interpretation is
@c done.
@c 
実際にはプログラムの一部でない他のターゲットに依存するプログラムを持つ
ことが役に立つこともあります.これは@samp{@var{prog}_DEPENDENCIES}変数
を使用することで可能になります.それぞれのプログラムはこの変数の内容に
依存しますが,それ以上の解釈はされません.

@c If @samp{@var{prog}_DEPENDENCIES} is not supplied, it is computed by
@c Automake.  The automatically-assigned value is the contents of
@c @samp{@var{prog}_LDADD}, with most configure substitutions, @samp{-l},
@c @samp{-L}, @samp{-dlopen} and @samp{-dlpreopen} options removed.  The
@c configure substitutions that are left in are only @samp{$(LIBOBJS)} and
@c @samp{$(ALLOCA)}; these are left because it is known that they will not
@c cause an invalid value for @samp{@var{prog}_DEPENDENCIES} to be
@c generated.
@c 
@samp{@var{prog}_DEPENDENCIES}が提供されていない場合,Automakeが考えま
す.自動的に割り当てられる値は@samp{@var{prog}_LDADD}の内容で,ほとん
どのconfigureの置換式,@samp{-l},@samp{-L},@samp{-dlopen},そして
@samp{-dlpreopen}オプションは削除されます.残っているconfigureの置換式
は,@samp{$(LIBOBJS)}と@samp{$(ALLOCA)}だけです.これらは,生成される
@samp{@var{prog}_DEPENDENCIES}に無効な値を与えないことが知られているの
で残されています.


@node Conditional Sources
@c @subsection Conditional compilation of sources
@subsection ソースの条件コンパイル

@c You can't put a configure substitution (e.g., @samp{@@FOO@@} or
@c @samp{$(FOO)} where @code{FOO} is defined via @code{AC_SUBST}) into a
@c @samp{_SOURCES} variable.  The reason for this is a bit hard to
@c explain, but suffice to say that it simply won't work.  Automake will
@c give an error if you try to do this.
@c 
@code{configure}の置換式(例えば,@code{AC_SUBST}で定義される@code{FOO} 
を用いた@samp{@@FOO@@}や@samp{$(FOO)})を@samp{_SOURCES} 変数に書き込む
ことはできません.この理由を説明するのは少し難しいのですが,単純に言っ
て動作しないということで十分でしょう.これを試みた場合,Automakeはエラー
を発します.

@c Fortunately there are two other ways to achieve the same result.  One is
@c to use configure substitutions in @code{_LDADD} variables, the other is
@c to use an Automake conditional.
@c 
幸い,同じ結果を達成するために二つの別の方法があります.一つは,
@code{configure}の置換式を@code{_LDADD}変数で使用する方法で,もう一つ
は,Automakeの条件式を使用する方法です.

@c @subsubsection Conditional compilation using @code{_LDADD} substitutions
@subsubsection @code{_LDADD}の置換式を使用した条件コンパイル

@cindex EXTRA_prog_SOURCES, defined

@c Automake must know all the source files that could possibly go into a
@c program, even if not all the files are built in every circumstance.  Any
@c files which are only conditionally built should be listed in the
@c appropriate @samp{EXTRA_} variable.  For instance, if
@c @file{hello-linux.c} or @file{hello-generic.c} were conditionally included
@c in @code{hello}, the @file{Makefile.am} would contain:
@c 
Automakeは,すべてのファイルが全ての状況でビルドされるわけではない場合
でも,プログラムに組み込まれる可能性があるソースファイルをすべて知って
いる必要があります.条件によってのみビルドされるファイルは,適切な
@samp{EXTRA_}変数でリストアップすべきです.例えば,条件によって
@file{hello-linux.c}や@file{hello-generic.c}を@code{hello}に組み込む場
合,@file{Makefile.am}に以下のものを含めます.

@example
bin_PROGRAMS = hello
hello_SOURCES = hello-common.c
EXTRA_hello_SOURCES = hello-linux.c hello-generic.c
hello_LDADD = $(HELLO_SYSTEM)
hello_DEPENDENCIES = $(HELLO_SYSTEM)
@end example

@noindent
@c You can then setup the @code{$(HELLO_SYSTEM)} substitution from
@c @file{configure.ac}:
@c 
@file{configure.ac}で@code{$(HELLO_SYSTEM)}の置換式を設定することが可
能です.

@example
@dots{}
case $host in
  *linux*) HELLO_SYSTEM='hello-linux.$(OBJEXT)' ;;
  *)       HELLO_SYSTEM='hello-generic.$(OBJEXT)' ;;
esac
AC_SUBST([HELLO_SYSTEM])
@dots{}
@end example

@c In this case, @code{HELLO_SYSTEM} should be replaced by
@c @file{hello-linux.o} or @file{hello-generic.o}, and added to
@c @code{hello_DEPENDENCIES} and @code{hello_LDADD} in order to be built
@c and linked in.
@c 
この場合,@code{HELLO_SYSTEM}は@file{hello-linux.o}や
@file{hello-generic.o}で置換され,ビルドしリンクするために
@code{hello_DEPENDENCIES}と@code{hello_LDADD}に追加されます.

@c @subsubsection Conditional compilation using Automake conditionals
@subsubsection Automakeの条件式を使用した条件コンパイル

@c An often simpler way to compile source files conditionally is to use
@c Automake conditionals.  For instance, you could use this
@c @file{Makefile.am} construct to build the same @file{hello} example:
@c 
条件によってソースファイルをコンパイルするためのより簡単な方法としては,
Automakeの条件式を使用することが多くなっています.例えば,同じ
@file{hello}の例をビルドするため,以下のような内容の@file{Makefile.am}
を使用することが可能でしょう.

@example
bin_PROGRAMS = hello
if LINUX
hello_SOURCES = hello-linux.c hello-common.c
else
hello_SOURCES = hello-generic.c hello-common.c
endif
@end example

@c In this case, your @file{configure.ac} should setup the @code{LINUX}
@c conditional using @code{AM_CONDITIONAL} (@pxref{Conditionals}).
@c 
この場合,@file{configure.ac}で@code{AM_CONDITIONAL}を使用して
@code{LINUX}条件式を設定する必要があります(@pxref{Conditionals}).

@c When using conditionals like this you don't need to use the
@c @samp{EXTRA_} variable, because Automake will examine the contents of
@c each variable to construct the complete list of source files.
@c 
Automakeは,ソースファイルの完全なリストを構成するためにそれぞれの変数
の内容を調査するので,このような条件を使用するときは,@samp{EXTRA_}変
数を使用する必要はありません.

@c If your program uses a lot of files, you will probably prefer a
@c conditional @code{+=}.
@c 
プログラムで多くのファイルを使用している場合,おそらく条件付の
@code{+=}のほうが望ましいでしょう.

@example
bin_PROGRAMS = hello
hello_SOURCES = hello-common.c
if LINUX
hello_SOURCES += hello-linux.c
else
hello_SOURCES += hello-generic.c
endif
@end example

@node Conditional Programs
@c @subsection Conditional compilation of programs
@subsection プログラムの条件付コンパイル
@cindex Conditional programs
@cindex Programs, conditional

@c Sometimes it is useful to determine the programs that are to be built
@c at configure time.  For instance, GNU @code{cpio} only builds
@c @code{mt} and @code{rmt} under special circumstances.  The means to
@c achieve conditional compilation of programs are the same you can use
@c to compile source files conditionally: substitutions or conditionals.
@c 
ビルドされるプログラムをconfigure時に決定することが役に立つときもあり
ます.例えば,GNU @code{cpio}は特別な状況のときだけ@code{mt}と
@code{rmt}をビルドします.プログラムの条件付きコンパイルを達成するとい
う意味は,ソースファイルのコンパイルを条件的に行なうことと一緒です.置
換式を用いたり条件式を用いたりします.

@c @subsubsection Conditional programs using @code{configure} substitutions
@subsubsection @code{configure}の置換式を使用した条件的プログラム

@c In this case, you must notify Automake of all the programs that can
@c possibly be built, but at the same time cause the generated
@c @file{Makefile.in} to use the programs specified by @code{configure}.
@c This is done by having @code{configure} substitute values into each
@c @samp{_PROGRAMS} definition, while listing all optionally built programs
@c in @code{EXTRA_PROGRAMS}.
@c 
この場合は,ビルドされる可能性のあるすべてのプログラムをAutomakeに知ら
せる必要がありますが,同時に,@code{configure}で指定されるプログラムを
使用するように@file{Makefile.in}を生成させる必要もあります.このことは,
それぞれの@samp{_PROGRAMS}定義に@code{configure}での置換式の値を持たせ
ることで行なわれますが,一方では,@code{EXTRA_PROGRAMS}でオプションと
してビルドされるプログラムがすべてリストアップされています.
@vindex EXTRA_PROGRAMS
@cindex EXTRA_PROGRAMS, defined

@example
bin_PROGRAMS = cpio pax $(MT)
libexec_PROGRAMS = $(RMT)
EXTRA_PROGRAMS = mt rmt
@end example

@c As explained in @ref{EXEEXT}, Automake will rewrite
@c @code{bin_PROGRAMS}, @code{libexec_PROGRAMS}, and
@c @code{EXTRA_PROGRAMS}, appending @code{$(EXEEXT)} to each binary.
@c Obviously it cannot rewrite values obtained at run-time through
@c @code{configure} substitutions, therefore you should take care of
@c appending @code{$(EXEEXT)} yourself, as in @code{AC_SUBST([MT],
@c ['mt$@{EXEEXT@}'])}.
@c 
@ref{EXEEXT}の説明として,Automakeは@code{$(EXEEXT)}をそれぞれのバイナ
リに付加して,@code{bin_PROGRAMS},@code{libexec_PROGRAMS},そして
@code{EXTRA_PROGRAMS}を書き換えます.@code{configure}の置換式で,実行
時に値を明示的に書き換えることは明らかに不可能なので,
@code{AC_SUBST([MT], ['mt$@{EXEEXT@}'])}の様に@code{$(EXEEXT)}を付加す
ることには気を付けて下さい.


@c @subsubsection Conditional programs using Automake conditionals
@subsubsection Automakeの条件式を使用した条件的プログラム

@c You can also use Automake conditionals (@pxref{Conditionals}) to
@c select programs to be built.  In this case you don't have to worry
@c about @code{$(EXEEXT)} or @code{EXTRA_PROGRAMS}.
@c 
ビルドするプログラムを選択するため,Automakeの条件式を
(@pxref{Conditionals})使用することも可能です.この状況では,
@code{$(EXEEXT)}や@code{EXTRA_PROGRAMS}に気を付ける必要はありません.

@example
bin_PROGRAMS = cpio pax
if WANT_MT
  bin_PROGRAMS += mt
endif
if WANT_RMT
  libexec_PROGRAMS = rmt
endif
@end example


@node A Library
@c @section Building a library
@section ライブラリのビルド

@cindex _LIBRARIES primary, defined
@cindex LIBRARIES primary, defined
@cindex Primary variable, LIBRARIES

@vindex lib_LIBRARIES
@vindex pkglib_LIBRARIES
@vindex noinst_LIBRARIES

@c Building a library is much like building a program.  In this case, the
@c name of the primary is @samp{LIBRARIES}.  Libraries can be installed in
@c @code{libdir} or @code{pkglibdir}.
@c 
ライブラリをビルドすることは,プログラムをビルドすることによく似ていま
す.この場合は,プライマリの名前は@samp{LIBRARIES}です.ライブラリは
@code{libdir}や@code{pkglibdir}にインストールされます.

@c @xref{A Shared Library}, for information on how to build shared
@c libraries using libtool and the @samp{LTLIBRARIES} primary.
@c 
libtoolと@samp{LTLIBRARIES}プライマリを使用して共有ライブラリをビルド
する方法についての詳細は,@xref{A Shared Library}.

@c Each @samp{_LIBRARIES} variable is a list of the libraries to be built.
@c For instance to create a library named @file{libcpio.a}, but not install
@c it, you would write:
@c 
それぞれの@samp{_LIBRARIES}変数は,ビルドされるライブラリのリストです.
例えば,@file{libcpio.a}という名前のライブラリを作成し,それをインストー
ルしないため,以下のように書きます.

@example
noinst_LIBRARIES = libcpio.a
@end example

@c The sources that go into a library are determined exactly as they are
@c for programs, via the @samp{_SOURCES} variables.  Note that the library
@c name is canonicalized (@pxref{Canonicalization}), so the @samp{_SOURCES}
@c variable corresponding to @file{liblob.a} is @samp{liblob_a_SOURCES},
@c not @samp{liblob.a_SOURCES}.
@c 
ライブラリに組み込まれるソースは,プログラムのときのように,
@samp{_SOURCES}変数によって正しく決定されます.ライブラリ名は標準的に
されるので(@pxref{Canonicalization}),@samp{liblob.a}に対応する
@samp{_SOURCES}変数は@samp{liblob.a_SOURCES}ではなく
@samp{liblob_a_SOURCES}になることに注意してください.

@cindex _LIBADD primary, defined
@cindex LIBADD primary, defined
@cindex Primary variable, LIBADD

@c Extra objects can be added to a library using the
@c @samp{@var{library}_LIBADD} variable.  This should be used for objects
@c determined by @code{configure}.  Again from @code{cpio}:
@c 
追加のオブジェクトは,@samp{@var{library}_LIBADD}変数を使用してライブ
ラリに追加することが可能です.これは@code{configure}で決定されるオブジェ
クトに対して使用されるべきです.再び@code{cpio}からの引用です.
@vindex _LIBADD
@vindex LIBADD

@example
libcpio_a_LIBADD = $(LIBOBJS) $(ALLOCA)
@end example

@c In addition, sources for extra objects that will not exist until
@c configure-time must be added to the @code{BUILT_SOURCES} variable
@c (@pxref{Sources}).
@c 
さらに,configure時まで存在しない追加のオブジェクトに対するソースは,
@code{BUILT_SOURCES}変数に追加する必要があります(@pxref{Sources}).

@c Building a static library is done by compiling all object files, then
@c by invoking @code{$(AR) $(ARFLAGS)} followed by the name of the
@c library and the list of objects, and finally by calling
@c @code{$(RANLIB)} on that library.  You should call
@c @code{AC_PROG_RANLIB} from your @file{configure.ac} to define
@c @code{RANLIB} (Automake will complain otherwise).  @code{AR} and
@c @code{ARFLAGS} default to @code{ar} and @code{cru} respectively; you
@c can override these two variables my setting them in your
@c @file{Makefile.am}, by @code{AC_SUBST}ing them from your
@c @file{configure.ac}, or by defining a per-library @code{maude_AR}
@c variable (@pxref{Program and Library Variables}).
@c 
スタティックライブラリをビルドすることは,すべてのオブジェクトファイル
をコンパイルし,その後で@code{$(AR) $(ARFLAGS)}にライブラリ名とオブジェ
クトのリストを続けたものを呼び出し,そして最後にライブラリで
@code{$(RANLIB)}を呼び出すことで達成されます.@code{RANLIB}を定義する
ため,@code{AC_PROG_RANLIB}を@file{configure.ac}から呼び出すべきです
(そうしなければ,Automakeは文句を言います).@code{AR}と@code{ARFLAGS} 
のデフォルトはそれぞれ@code{ar}と@code{cru}です.これらの二つの変数を
@file{Makefile.am}で設定する,@file{configure.ac}で@code{AC_SUBST}する,
または,ライブラリごとに@code{maude_AR}変数で定義することで優先させる
ことが可能です(@pxref{Program and Library Variables}).

@node A Shared Library
@c @section Building a Shared Library
@section 共有ライブラリのビルド

@cindex Shared libraries, support for

@c Building shared libraries portably is a relatively complex matter.
@c For this reason, GNU Libtool (@pxref{Top, , Introduction, libtool, The
@c Libtool Manual}) was created to help build shared libraries in a
@c platform-independent way.
@c 
移植性の高い共有ライブラリをビルドすることは比較的複雑な問題です.この
ために,GNU Libtoolは(@pxref{Top, , Introduction, libtool, The Libtool
Manual})プラットホームに依存しない方法で共有ライブラリをビルドする補助
を行なうために作成されました.

@menu
* Libtool Concept::             Introducing Libtool
* Libtool Libraries::           Declaring Libtool Libraries
* Conditional Libtool Libraries::  Building Libtool Libraries Conditionally
* Conditional Libtool Sources::  Choosing Library Sources Conditionally
* Libtool Convenience Libraries::  Building Convenience Libtool Libraries
* Libtool Modules::             Building Libtool Modules
* Libtool Flags::               Using _LIBADD and _LDFLAGS
* LTLIBOBJ::                    Using $(LTLIBOBJ)
* Libtool Issues::              Common Issues Related to Libtool's Use
@end menu

@node Libtool Concept
@c @subsection The Libtool Concept
@subsection Libtoolの概念

@cindex libtool, introduction
@cindex libtool library, definition
@cindex suffix .la, defined
@cindex .la suffix, defined

@c Libtool abstracts shared and static libraries into a unified
@c concept henceforth called @dfn{libtool libraries}.  Libtool libraries
@c are files using the @file{.la} suffix, and can designate a static
@c library, a shared library, or maybe both.  Their exact nature cannot
@c be determined until @file{./configure} is run: not all platforms
@c support all kinds of libraries, and users can explicitly select which
@c libraries should be built.  (However the package's maintainers can
@c tune the default, @xref{AC_PROG_LIBTOOL, , The @code{AC_PROG_LIBTOOL}
@c macro, libtool, The Libtool Manual}.)
@c 
Libtoolは,共有ライブラリとスタティックライブラリを統一した概念で,
@dfn{libtoolライブラリ(libtool libraries)}と呼ばれるものに抽出します.
Libtoolライブラリは@file{.la}接尾子を使用しているファイルで,スタティッ
クライブラリ,共有ライブラリ,または両方を表します.正確な性質は
@file{./configure}が実行されるまで決定することは不可能です.すべてのプ
ラットフォームですべての種類のライブラリをサポートしているわけではあり
ませんし,ユーザは明示的にビルドするライブラリを選択するすることも可能
です.(しかし,パッケージの管理者はデフォルトを調整することが可能です.
@xref{AC_PROG_LIBTOOL, , The @code{AC_PROG_LIBTOOL} macro, libtool,
The Libtool Manual}.)

@cindex suffix .lo, defined
@c Because object files for shared and static libraries must be compiled
@c differently, libtool is also used during compilation.  Object files
@c built by libtool are called @dfn{libtool objects}: these are files
@c using the @file{.lo} suffix.  Libtool libraries are built from these
@c libtool objects.
@c 
共有ライブラリとスタティックライブラリのオブジェクトファイルは,別々に
コンパイルする必要があるので,libtoolはコンパイル時にも使用されます.
libtoolでビルドされたライブラリは,@dfn{libtoolオブジェクト(libtool
objects)}と呼ばれます.これらは,@file{.lo}接尾子を利用しているファイ
ルです.libtoolライブラリはこれらのlibtoolオブジェクトからビルドされま
す.

@c You should not assume anything about the structure of @file{.la} or
@c @file{.lo} files and how libtool constructs them: this is libtool's
@c concern, and the last thing one wants is to learn about libtool's
@c guts.  However the existence of these files matters, because they are
@c used as targets and dependencies in @file{Makefile}s rules when
@c building libtool libraries.  There are situations where you may have
@c to refer to these, for instance when expressing dependencies for
@c building source files conditionally (@pxref{Conditional Libtool
@c Sources}).
@c 
@file{.la}や@file{.lo}ファイルの構造や,libtoolがそれらを構築する方法
を仮定すべきではありません.これはlibtoolが考えることで,最後のものは
libtoolの中身を勉強したい人が欲しいものです.しかし,これらのファイル
は,libtoolライブラリをビルドするとき,@file{Makefile}ルール内のターゲッ
トと依存性として使用されるので,その存在が重要になります.例えば,条件
的にソースファイルをビルドする依存性を表現するとき,これらを参照する必
要がある状況があります(@pxref{Conditional Libtool Sources}).

@cindex libltdl, introduction

@c People considering writing a plug-in system, with dynamically loaded
@c modules, should look into @file{libltdl}: libtool's dlopening library
@c (@pxref{Using libltdl, , Using libltdl, libtool, The Libtool Manual}).
@c This offers a portable dlopening facility to load libtool libraries
@c dynamically, and can also achieve static linking where unavoidable.
@c 
動的にロードされるモジュールとなっているプラグインシステムを書こうと考
えている人々は,@file{libltdl}の中を見るべきです.libtoolによるライブ
ラリのdlopenです(@pxref{Using libltdl, , Using libltdl, libtool, The
Libtool Manual}).これは,libtoolライブラリを動的にロードするための移
植性の高いdlopenを提供し,やむをえないところではスタティックにリンクす
ることも可能です.

@c Before we discuss how to use libtool with Automake in details, it
@c should be noted that the libtool manual also has a section about how
@c to use Automake with libtool (@pxref{Using Automake, , Using Automake
@c with Libtool, libtool, The Libtool Manual}).
@c 
我々がAutomakeを用いてlibtoolを使用する方法の詳細を議論する前に,
libtoolマニュアルにあるlibtoolとともにAutomakeを使用する方法に付いて書
かれているセクションにも注意しておくべきです(@pxref{Using Automake, ,
Using Automake with Libtool, libtool, The Libtool Manual}).

@node Libtool Libraries
@c @subsection Building Libtool Libraries
@subsection Libtoolライブラリのビルド

@cindex _LTLIBRARIES primary, defined
@cindex LTLIBRARIES primary, defined
@cindex Primary variable, LTLIBRARIES
@cindex Example of shared libraries
@vindex lib_LTLIBRARIES
@vindex pkglib_LTLIBRARIES

@c Automake uses libtool to build libraries declared with the
@c @samp{LTLIBRARIES} primary.  Each @samp{_LTLIBRARIES} variable is a
@c list of libtool libraries to build.  For instance, to create a libtool
@c library named @file{libgettext.la}, and install it in @samp{libdir},
@c write:
@c 
Automakeは,@samp{LTLIBRARIES}プライマリで宣言されたライブラリをビルド
するためにLibtoolを使用します.それぞれの@samp{_LTLIBRARIES}変数はビル
ドするlibtoolライブラリのリストです.例えば,@file{libgettext.la}とい
う名前のlibtoolライブラリを作成し,@samp{libdir}にインストールするため
に,以下のように書いてください.

@example
lib_LTLIBRARIES = libgettext.la
libgettext_la_SOURCES = gettext.c gettext.h @dots{}
@end example

@c Automake predefines the variable @samp{pkglibdir}, so you can use
@c @code{pkglib_LTLIBRARIES} to install libraries in
@c @code{$(libdir)/@@PACKAGE@@/}.
@c 
Automakeは変数@samp{pkglibdir}を前もって定義しているので,ライブラリを
@code{$(libdir)/@@PACKAGE@@/}にインストールするために,
@code{pkglib_LTLIBRARIES}を使用することが可能です.

@node Conditional Libtool Libraries
@c @subsection Building Libtool Libraries Conditionally
@subsection Libtoolライブラリのビルドの条件分岐
@cindex libtool libraries, conditional
@cindex conditional libtool libraries

@c Like conditional programs (@pxref{Conditional Programs}), there are
@c two main ways to build conditional libraries: using Automake
@c conditionals or using Autoconf @code{AC_SUBST}itutions.
@c 
プログラムの条件式のように(@pxref{Conditional Programs}),ライブラリの
条件付きビルドにも主に二つの方法があります.Automakeの条件式を使用する
方法と,Autoconfの@code{AC_SUBST}を使用する方法です.

@c The important implementation detail you have to be aware of is that
@c the place where a library will be installed matters to libtool: it
@c needs to be indicated @emph{at link-time} using the @code{-rpath}
@c option.
@c 
気を付けるべき重要な実装の詳細は,ライブラリがインストールされる場所が
libtoolにとって重要だということです.それは,@code{-rpath}オプションを
使用して@emph{リンク時に}示されるものが必要になります.

@c For libraries whose destination directory is known when Automake runs,
@c Automake will automatically supply the appropriate @samp{-rpath}
@c option to libtool. This is the case for libraries listed explicitly in
@c some installable @code{_LTLIBRARIES} variables such as
@c @code{lib_LTLIBRARIES}.
@c 
Automakeの実行時にインストール先のディレクトリが分かっているライブラリ
に対し,Automakeは自動的に適切な@samp{-rpath}オプションをlibtoolに供給
します.これは,@code{lib_LTLIBRARIES}のように,インストール可能な
@code{_LTLIBRARIES}に明示的にリストアップされているライブラリの場合で
す.

@c However, for libraries determined at configure time (and thus
@c mentioned in @code{EXTRA_LTLIBRARIES}), Automake does not know the
@c final installation directory.  For such libraries you must add the
@c @samp{-rpath} option to the appropriate @samp{_LDFLAGS} variable by
@c hand.
@c 
しかし,configure時に決定される(@code{EXTRA_LTLIBRARIES}に記述されてい
る)ライブラリに対して,Automakeは最終的なインストールディレクトリが分
かりません.そのようなライブラリに対して,適切な@samp{_LDFLAGS}変数に
@samp{-rpath}オプションを手動で追加する必要があります.

@c The examples below illustrate the differences between these two methods.
@c 
以下の例で,これら二つの手法の違いを説明します.

@c Here is an example where @code{$(WANTEDLIBS)} is an @code{AC_SUBST}ed
@c variable set at @file{./configure}-time to either @file{libfoo.la},
@c @file{libbar.la}, both, or none.  Although @code{$(WANTEDLIBS)}
@c appears in the @code{lib_LTLIBRARIES}, Automake cannot guess it
@c relates to @file{libfoo.la} or @file{libbar.la} by the time it creates
@c the link rule for these two libraries.  Therefore the @code{-rpath}
@c argument must be explicitly supplied.
@c 
この例は,@code{$(WANTEDLIBS)}が@code{AC_SUBST}されている変数で,
@file{./configure}時に@file{libfoo.la},@file{libbar.la},その両方,ま
たは空で設定されます.@code{$(WANTEDLIBS)}は@code{lib_LTLIBRARIES}に書
かれていますが,Automakeは,それが@file{libfoo.la}または
@file{libbar.la}に関連付けされることを,これら二つのライブラリに対する
リンクルールが作成されるときまで推測することが不可能です.このため,特
に@code{-rpath}引数を提供する必要があります.

@example
EXTRA_LTLIBRARIES = libfoo.la libbar.la
lib_LTLIBRARIES = $(WANTEDLIBS)
libfoo_la_SOURCES = foo.c @dots{}
libfoo_la_LDFLAGS = -rpath '$(libdir)'
libbar_la_SOURCES = bar.c @dots{}
libbar_la_LDFLAGS = -rpath '$(libdir)'
@end example

@c Here is how the same @file{Makefile.am} would look using Automake
@c conditionals named @code{WANT_LIBFOO} and @code{WANT_LIBBAR}.  Now
@c Automake is able to compute the @code{-rpath} setting itself, because
@c it's clear that both libraries will end up in @code{$(libdir)} if they
@c are installed.
@c 
これは,同じ@file{Makefile.am}で,@code{WANT_LIBFOO}と
@code{WANT_LIBBAR}という名前のAutomakeの条件式を使用しているものがあり
ます.Automakeは,両方のライブラリをインストールする場合,結局
@code{$(libdir)}になることが明らかなので,@code{-rpath}の設定を自分で
計算することが可能です.

@example
lib_LTLIBRARIES =
if WANT_LIBFOO
lib_LTLIBRARIES += libfoo.la
endif
if WANT_LIBBAR
lib_LTLIBRARIES += libbar.la
endif
libfoo_la_SOURCES = foo.c @dots{}
libbar_la_SOURCES = bar.c @dots{}
@end example

@node Conditional Libtool Sources
@c @subsection Libtool Libraries with Conditional Sources
@subsection 条件的ソースを用いたLibtoolライブラリ

@c Conditional compilation of sources in a library can be achieved in the
@c same way as conditional compilation of sources in a program
@c (@pxref{Conditional Sources}).  The only difference is that
@c @code{_LIBADD} should be used instead of @code{_LDADD} and that it
@c should mention libtool objects (@file{.lo} files).
@c 
ライブラリでのソースの条件的コンパイルは,プログラムでのソースの条件的
コンパイルと同じ方法で達成することが可能です(@pxref{Conditional
Sources}).違いは,@code{_LDADD}の代わりに@code{_LIBADD}を使用し,
libtoolオブジェクト(@file{.lo}ファイル)について記述することだけです.

@c So, to mimic the @file{hello} example from @ref{Conditional Sources},
@c we could build a @file{libhello.la} library using either
@c @file{hello-linux.c} or @file{hello-generic.c} with the following
@c @file{Makefile.am}.
@c 
そのため,@ref{Conditional Sources}の@file{hello}の例を真似てみると,
以下のような@file{Makefile.am}を用いて@file{hello-linux.c}または
@file{hello-generic.c}のいずれかを使用して@file{libhello.la}ライブラリ
をビルドすることが可能でしょう.

@example
lib_LTLIBRARIES = libhello.la
libhello_la_SOURCES = hello-common.c
EXTRA_libhello_la_SOURCES = hello-linux.c hello-generic.c
libhello_la_LIBADD = $(HELLO_SYSTEM)
libhello_la_DEPENDENCIES = $(HELLO_SYSTEM)
@end example

@noindent
@c And make sure @code{$(HELLO_SYSTEM)} is set to either
@c @file{hello-linux.lo} or @file{hello-generic.lo} in
@c @file{./configure}.
@c 
そして,@code{$(HELLO_SYSTEM)}が@file{./configure}で
@file{hello-linux.lo}または@file{hello-generic.lo}のいずれかに設定され
ていることを確かめて下さい.

@c Or we could simply use an Automake conditional as follows.
@c 
また,Automake条件式を使用して以下のように簡単にすることも可能でしょう.

@example
lib_LTLIBRARIES = libhello.la
libhello_la_SOURCES = hello-common.c
if LINUX
libhello_la_SOURCES += hello-linux.c
else
libhello_la_SOURCES += hello-generic.c
endif
@end example

@node Libtool Convenience Libraries
@c @subsection Libtool Convenience Libraries
@subsection Libtoolのコンビニエンスライブラリ
@cindex convenience libraries, libtool
@cindex libtool convenience libraries
@vindex noinst_LTLIBRARIES
@vindex check_LTLIBRARIES

@c Sometimes you want to build libtool libraries which should not be
@c installed.  These are called @dfn{libtool convenience libraries} and
@c are typically used to encapsulate many sublibraries, later gathered
@c into one big installed library.
@c 
インストールされないlibtoolライブラリをビルドしたいときもあります.こ
れらは,@dfn{libtoolコンビニエンスライブラリ(libtool convenience
libraries)}と呼ばれ,通常多くのサブライブラリをカプセル化し,後でイン
ストールされる大きな一つのライブラリにまとめるときに使用されます.

@c Libtool convenience libraries are declared by
@c @code{noinst_LTLIBRARIES}, @code{check_LTLIBRARIES}, or even
@c @code{EXTRA_LTLIBRARIES}.  Unlike installed libtool libraries they do
@c not need an @code{-rpath} flag at link time (actually this is the only
@c difference).
@c 
libtoolコンビニエンスライブラリは,@code{noinst_LTLIBRARIES},
@code{check_LTLIBRARIES},または@code{EXTRA_LTLIBRARIES}でも宣言されま
す.インストールされるlibtoolライブラリと異なり,それらはリンク時に
@code{-rpath}フラグが不要です(実際,これが違うだけです).

@c Convenience libraries listed in @code{noinst_LTLIBRARIES} are always
@c built.  Those listed in @code{check_LTLIBRARIES} are built only upon
@c @code{make check}.  Finally, libraries listed in
@c @code{EXTRA_LTLIBRARIES} are never built explicitly: Automake outputs
@c rules to build them, but if the library does not appear as a Makefile
@c dependency anywhere it won't be built (this is why
@c @code{EXTRA_LTLIBRARIES} is used for conditional compilation).
@c 
@code{noinst_LTLIBRARIES}でリストアップされているコンビニエンスライブ
ラリは,常にビルドされます.@code{check_LTLIBRARIES}にリストアップされ
ているものは,@code{make check}のときだけビルドされます.最後に,
@code{EXTRA_LTLIBRARIES}でリストアップされているライブラリは,明示的に
はビルドされません.Automakeはそれらのビルドルールを出力しますが,ライ
ブラリがMakefileの依存性に表れない場合はビルドされません(これは,
@code{EXTRA_LTLIBRARIES}が条件付きコンパイルで使用されるためです).

@c Here is a sample setup merging libtool convenience libraries from
@c subdirectories into one main @file{libtop.la} library.
@c 
サブディレクトリのlibtoolコンビニエンスライブラリを,一つの中心となる
@file{libtop.la}ライブラリにまとめる設定例は以下のようになります.

@example
# -- Top-level Makefile.am --
SUBDIRS = sub1 sub2 @dots{}
lib_LTLIBRARIES = libtop.la
libtop_la_SOURCES =
libtop_la_LIBADD = \
  sub1/libsub1.la \
  sub2/libsub2.la \
  @dots{}

# -- sub1/Makefile.am --
noinst_LTLIBRARIES = libsub1.la
libsub1_la_SOURCES = @dots{}

# -- sub2/Makefile.am --
# showing nested convenience libraries
SUBDIRS = sub2.1 sub2.2 @dots{}
noinst_LTLIBRARIES = libsub2.la
libsub2_la_SOURCES =
libsub2_la_LIBADD = \
  sub21/libsub21.la \
  sub22/libsub22.la \
  @dots{}
@end example

@node Libtool Modules
@c @subsection Libtool Modules
@subsection Libtoolのモジュール
@cindex modules, libtool
@cindex libtool modules
@cindex -module, libtool

@c These are libtool libraries meant to be dlopened.  They are
@c indicated to libtool by passing @code{-module} at link-time.
@c 
これらは,dlopenされることを意味するlibtoolライブラリです.それらは,
リンク時に@code{-module}をlibtoolに渡すことで示されます.

@example
pkglib_LTLIBRARIES = mymodule.la
mymodule_la_SOURCES = doit.c
mymodule_la_LDFLAGS = -module
@end example

@c Ordinarily, Automake requires that a Library's name starts with
@c @samp{lib}.  However, when building a dynamically loadable module you
@c might wish to use a "nonstandard" name.
@c 
通常,Automakeは共有ライブラリの名前が@samp{lib}で始まることを要求しま
す.しかし,動的にロードされるモジュールをビルドしている場合,"標準的
でない" 名前を使用したいかもしれません.

@c If @samp{mymodule_la_SOURCES} is not specified, then it defaults to the single
@c file @file{mymodule.c} (@pxref{Default _SOURCES}).
@c 
@samp{mymodule_la_SOURCES}が指定されていない場合,そのデフォルトは単一
ファイルの@file{mymodule.c} (@pxref{Default _SOURCES})です.

@node Libtool Flags
@c @subsection _LIBADD and _LDFLAGS
@subsection _LIBADDと_LDFLAGS
@cindex _LIBADD, libtool
@cindex _LDFLAGS, libtool

@c As shown in previous sections, the @samp{@var{library}_LIBADD}
@c variable should be used to list extra libtool objects (@file{.lo}
@c files) or libtool libraries (@file{.la}) to add to @var{library}.
@c 
前のセクションで見てきたように,@samp{@var{library}_LIBADD}変数は,
@var{library}に追加する補助的なlibtoolオブジェクト(@file{.lo}ファイル) 
やlibtoolライブラリ(@file{.la})をリストアップするために使用すべきです.

@c The @samp{@var{library}_LDFLAGS} variable is the place to list
@c additional libtool flags, such as @samp{-version-info},
@c @samp{-static}, and a lot more.  See @xref{Link mode, , Using libltdl,
@c libtool, The Libtool Manual}.
@c 
@samp{@var{library}_LDFLAGS}変数には,@samp{-version-info},
@samp{-static},などの追加のlibtoolフラグをリストアップします.
@xref{Link mode, , Using libltdl, libtool, The Libtool Manual}.

@node LTLIBOBJ, Libtool Issues, Libtool Flags, A Shared Library
@subsection @code{LTLIBOBJS}
@cindex @code{LTLIBOBJS}, special handling
@vindex LTLIBOBJS
@vindex LIBOBJS
@cvindex AC_LIBOBJ

@c Where an ordinary library might include @code{$(LIBOBJS)}, a libtool
@c library must use @code{$(LTLIBOBJS)}.  This is required because the
@c object files that libtool operates on do not necessarily end in
@c @file{.o}.
@c 
通常のライブラリは@code{$(LIBOBJS)}に含まれますが,libtoolライブラリは
@code{$(LTLIBOBJS)}を使用する必要があります.libtoolが処理するオブジェ
クトファイルは,最終的に@file{.o}にする必要がないため,このように要求
されます.

@c Nowadays, the computation of @code{LTLIBOBJS} from @code{LIBOBJS} is
@c performed automatically by Autoconf (@pxref{AC_LIBOBJ vs LIBOBJS, ,
@c @code{AC_LIBOBJ} vs. @code{LIBOBJS}, autoconf, The Autoconf Manual}).
@c 
現在,@code{LIBOBJS}から@code{LTLIBOBJS}を求めることはAutoconfが自動的
に実行します(@pxref{AC_LIBOBJ vs LIBOBJS, , @code{AC_LIBOBJ}
vs. @code{LIBOBJS}, autoconf, The Autoconf Manual}).

@node Libtool Issues
@c @subsection Common Issues Related to Libtool's Use
@subsection Libtoolの使用に関連する一般的な問題

@subsubsection @code{required file `./ltmain.sh' not found}
@cindex ltmain.sh not found
@cindex libtoolize, no longer run by Automake
@cindex libtoolize and autoreconf
@cindex autoreconf and libtoolize
@cindex bootstrap.sh and autoreconf
@cindex autogen.sh and autoreconf

@c Libtool comes with a tool called @command{libtoolize} that will
@c install libtool's supporting files into a package.  Running this
@c command will install @file{ltmain.sh}.  You should execute it before
@c @command{aclocal} and @command{automake}.
@c 
libtoolは,パッケージにlibtoolのサポートを行なうファイルをインストール
する@command{libtoolize}と呼ばれるツールから生じます.このコマンドを実
行すると,@file{ltmain.sh}がインストールされます.@command{aclocal}と
@command{automake}の前にそれを実行すべきです.

@c People upgrading old packages to newer autotools are likely to face
@c this issue because older Automake versions used to call
@c @command{libtoolize}.  Therefore old build scripts do not call
@c @command{libtoolize}.
@c 
古いパッケージから新しいautotoolにアップグレードすると,古いバージョン
のAutomakeは@command{libtoolize}と呼ばれるものを使用していたのでこの問
題に直面します.このため,古いビルドスクリプトでは@command{libtoolize} 
を呼び出しません.

@c Since Automake 1.6, it has been decided that running
@c @command{libtoolize} was none of Automake's business.  Instead, that
@c functionality has been moved into the @command{autoreconf} command
@c (@pxref{autoreconf Invocation, , Using @command{autoreconf}, autoconf,
@c The Autoconf Manual}).  If you do not want to remember what to run and
@c when, just learn the @command{autoreconf} command.  Hopefully,
@c replacing existing @file{bootstrap.sh} or @file{autogen.sh} scripts by
@c a call to @command{autoreconf} should also free you from any similar
@c incompatible change in the future.
@c 
Automake1.6から,@command{libtoolize}の実行がAutomakeの仕事ではないと
決定しました.その代わり,その機能は@command{autoreconf}コマンドに渡さ
れました(@pxref{autoreconf Invocation, , Using @command{autoreconf},
autoconf, The Autoconf Manual}).いつ何を実行するのか覚えたくない場合,
@command{autoreconf}コマンドだけを勉強して下さい.希望的には,既存の
@file{bootstrap.sh}や@file{autogen.sh}スクリプトを@command{autoreconf} 
の呼び出しに置換することで,将来においても同様の互換性の無い変更から自
由になれるでしょう.

@c @subsubsection Objects @code{created with both libtool and without}
@subsubsection libtoolで作成されたりされなかったりするオブジェクト

@c Sometimes, the same source file is used both to build a libtool
@c library and to build another non-libtool target (be it a program or
@c another library).
@c 
同じソースファイルが,libtoolライブラリのビルドと,libtoolではない他の
ターゲット(プログラムだったり,他のライブラリだったりします)をビルドす
るために使用されることもあります.

@c Let's consider the following @file{Makefile.am}.
@c 
以下の@file{Makefile.am}を考えてみましょう.

@example
bin_PROGRAMS = prog
prog_SOURCES = prog.c foo.c @dots{}

lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = foo.c @dots{}
@end example

@noindent
@c (In this trivial case the issue could be avoided by linking
@c @file{libfoo.la} with @file{prog} instead of listing @file{foo.c} in
@c @code{prog_SOURCES}.  But let's assume we really want to keep
@c @file{prog} and @file{libfoo.la} separate.)
@c 
(この平凡な状況では,@code{prog_SOURCES}にリストアップされている
@file{foo.c}の代わりに,@file{prog}を用いて@file{libfoo.la}をリンクす
ることを避けることで,問題を回避することが可能です.しかし,実際には
@file{prog}と@file{libfoo.la}は別々に保持したいと仮定します.)

@c Technically, it means that we should build @file{foo.$(OBJEXT)} for
@c @file{prog}, and @file{foo.lo} for @file{libfoo.la}.  The problem is
@c that in the course of creating @file{foo.lo}, libtool may erase (or
@c replace) @file{foo.$(OBJEXT)} -- and this cannot be avoided.
@c 
技術的には,我々は@file{prog}に対して@file{foo.$(OBJEXT)}をビルドし,
@file{libfoo.la}に対して@file{foo.lo}をビルドべきだということを意味し
ます.問題は,@file{foo.lo}を作成する仮定で,libtoolが
@file{foo.$(OBJEXT)}を削除(または置換)する可能性があるということです 
-- これは避けられません.

@c Therefore, when Automake detects this situation it will complain
@c with a message such as
@c 
このため,Automakeがこの状況を検出すると,以下のようなメッセージで文句
を言います.
@example
object `foo.$(OBJEXT)' created both with libtool and without
@end example

@c A workaround for this issue is to ensure that these two objects get
@c different basenames.  As explained in @ref{renamed objects}, this
@c happens automatically when per-targets flags are used.
@c 
この問題を回避する方法は,これら二つのオブジェクトを確実に異なるベース
名にすることです.@ref{renamed objects}で説明されているように,ターゲッ
トごとのフラグが使用されているとき,これは自動的に行なわれます.

@example
bin_PROGRAMS = prog
prog_SOURCES = prog.c foo.c @dots{}
prog_CFLAGS = $(AM_CFLAGS)

lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = foo.c @dots{}
@end example

@noindent
@c Adding @code{prog_CFLAGS = $(AM_CFLAGS)} is almost a no-op, because
@c when the @code{prog_CFLAGS} is defined, it is used instead of
@c @code{AM_CFLAGS}.  However as a side effect it will cause
@c @file{prog.c} and @file{foo.c} to be compiled as
@c @file{prog-prog.$(OBJEXT)} and @file{prog-foo.$(OBJEXT)} which solves
@c the issue.
@c 
@code{prog_CFLAGS = $(AM_CFLAGS)}の追加は,@code{prog_CFLAGS}が定義さ
れているとき,@code{AM_CFLAGS}の代わりにそれを使用するので,ほとんど何
もしません.しかし,副作用として,@file{prog.c}と@file{foo.c}を
@file{prog-prog.$(OBJEXT)}と@file{prog-foo.$(OBJEXT)}にコンパイルし,
問題を解決することになります.

@node Program and Library Variables
@c @section Program and Library Variables
@section プログラムとライブラリの変数

@c Associated with each program are a collection of variables which can be
@c used to modify how that program is built.  There is a similar list of
@c such variables for each library.  The canonical name of the program (or
@c library) is used as a base for naming these variables.
@c 
それぞれのプログラムに関連して,プログラムのビルドの方法を修正するため
に使用可能な変数の集合があります.それぞれのライブラリに対しても,それ
に似たような変数のリストがあります.プログラム(やライブラリ)の標準的な
名前が,これらの変数の命名に対してベースとして使用されます.

@c In the list below, we use the name ``maude'' to refer to the program or
@c library.  In your @file{Makefile.am} you would replace this with the
@c canonical name of your program.  This list also refers to ``maude'' as a
@c program, but in general the same rules apply for both static and dynamic
@c libraries; the documentation below notes situations where programs and
@c libraries differ.
@c 
以下のリストでは,名前``maude''をプログラムやライブラリを示すものとし
て使用しています.@file{Makefile.am}で,これをプログラムの標準的な名前
に置換してください.このリストは,``maude''をプログラムを示すものとし
ていますが,一般的に同じルールを,スタティックライブラリやダイナミック
ライブラリに適用します.以下の文章では,プログラムとライブラリで異なる
状況をコメントしています.

@table @samp
@item maude_SOURCES
@c This variable, if it exists, lists all the source files which are
@c compiled to build the program.  These files are added to the
@c distribution by default.  When building the program, Automake will cause
@c each source file to be compiled to a single @file{.o} file (or
@c @file{.lo} when using libtool).  Normally these object files are named
@c after the source file, but other factors can change this.  If a file in
@c the @samp{_SOURCES} variable has an unrecognized extension, Automake
@c will do one of two things with it.  If a suffix rule exists for turning
@c files with the unrecognized extension into @file{.o} files, then
@c automake will treat this file as it will any other source file
@c (@pxref{Support for Other Languages}).  Otherwise, the file will be
@c ignored as though it were a header file.
@c 
存在する場合,この変数は,プログラムをビルドするためにコンパイルされる,
すべてのソースファイルをリストアップします.プログラムをビルドしている
とき,Automakeはそれぞれのソースファイルを単一の@file{.o}ファイル(や
libtoolを使用しているときは@file{.lo})にコンパイルさせます.通常これら
のオブジェクトファイルはソースファイルの後に命名されますが,他の要因で
変更することが可能です.@samp{_SOURCES}変数のファイルに認識できない拡
張子がある場合,Automakeは二つのうちの一つを実行します.認識できない拡
張子を持つファイルを@file{.o}に変換するためのサフィックスルールが存在
する場合,automakeはこのファイルを,その他の(言語の)ソースファイルとし
て扱います(@pxref{Support for Other Languages}).それ以外では,ファイ
ルがヘッダファイルと考えて無視されます.

@c The prefixes @samp{dist_} and @samp{nodist_} can be used to control
@c whether files listed in a @samp{_SOURCES} variable are distributed.
@c @samp{dist_} is redundant, as sources are distributed by default, but it
@c can be specified for clarity if desired.
@c 
接頭辞の@samp{dist_}と@samp{nodist_}で,@samp{_SOURCES}にリストアップ
されているファイルを配布するかどうか制御するために使用することが可能で
す.ソースはデフォルトで配布されるので,@samp{dist_}は冗長ですが,必要
があれば明確にするために指定可能です.

@c It is possible to have both @samp{dist_} and @samp{nodist_} variants of
@c a given @samp{_SOURCES} variable at once; this lets you easily
@c distribute some files and not others, for instance:
@c 
@samp{_SOURCES}変数に与えるものとして@samp{dist_}と@samp{nodist_}の両
方を一度に用いることが可能です.これによって,配布するファイルとしない
ものに簡単に分類することができ,例えば以下のようにします.

@example
nodist_maude_SOURCES = nodist.c
dist_maude_SOURCES = dist-me.c
@end example

@c By default the output file (on Unix systems, the @file{.o} file) will be
@c put into the current build directory.  However, if the option
@c @code{subdir-objects} is in effect in the current directory then the
@c @file{.o} file will be put into the subdirectory named after the source
@c file.  For instance, with @code{subdir-objects} enabled,
@c @file{sub/dir/file.c} will be compiled to @file{sub/dir/file.o}.  Some
@c people prefer this mode of operation.  You can specify
@c @code{subdir-objects} in @code{AUTOMAKE_OPTIONS} (@pxref{Options}).
@c 
デフォルトで,出力ファイル(Unixシステム上では@file{.o}ファイル)は,現
在のビルドディレクトリに書き込まれます.しかし,現在のディレクトリに対
してオプションの@code{subdir-objects}の影響がある場合,@file{.o}ファイ
ルはソースファイルの後で指名されるサブディレクトリに書き込まれます.例
えば,@code{subdir-objects}が利用可能な場合,@file{sub/dir/file.c}は
@file{sub/dir/file.o}にコンパイルされます.この処理モードを好む人もい
ます.@code{subdir-objects}を@code{AUTOMAKE_OPTIONS}で指定することが可
能です(@pxref{Options}).
@cindex Subdirectory, objects in
@cindex Objects in subdirectory


@item EXTRA_maude_SOURCES
@c Automake needs to know the list of files you intend to compile
@c @emph{statically}.  For one thing, this is the only way Automake has of
@c knowing what sort of language support a given @file{Makefile.in}
@c requires.  @footnote{There are other, more obscure reasons for
@c this limitation as well.}  This means that, for example, you can't put a
@c configure substitution like @samp{@@my_sources@@} into a @samp{_SOURCES}
@c variable.  If you intend to conditionally compile source files and use
@c @file{configure} to substitute the appropriate object names into, e.g.,
@c @samp{_LDADD} (see below), then you should list the corresponding source
@c files in the @samp{EXTRA_} variable.
@c 
Automakeは,コンパイルしたいファイルのリストを@emph{静的に}知っている
必要があります.一つには,該当する@file{Makefile.in}が要求する言語のサ
ポートの種類をAutomakeが知るための唯一の方法だということがあげられます.
@footnote{それ以外にも,この制限に対してあまり知られていない理由も存在
します.}例えばこれには,@samp{@@my_sources@@}のようなconfigureの置換
式を@samp{_SOURCES}に書き込むことができないという意味があります.ソー
スファイルの条件コンパイルを行ない,例えば@samp{_LDADD}(以下を参照して
ください)のオブジェクト名を適切に置換するために@file{configure}を使用
したい場合,対応するソースファイルを@samp{EXTRA_}にリストアップした方
が良いでしょう.

@c This variable also supports @samp{dist_} and @samp{nodist_} prefixes,
@c e.g., @samp{nodist_EXTRA_maude_SOURCES}.
@c 
この変数は,例えば@samp{nodist_EXTRA_maude_SOURCES}のように,
@samp{dist_}と@samp{nodist_}もサポートします.

@item maude_AR
@c A static library is created by default by invoking @code{$(AR)
@c $(ARFLAGS)} followed by the name of the library and then the objects
@c being put into the library.  You can override this by setting the
@c @samp{_AR} variable.  This is usually used with C++; some C++
@c compilers require a special invocation in order to instantiate all the
@c templates which should go into a library.  For instance, the SGI C++
@c compiler likes this variable set like so:
@c 
スタティックライブラリは,デフォルトで,@code{$(AR) $(ARFLAGS)}にライ
ブラリ名とライブラリに書き込むオブジェクトを続けて呼び出すことで作成さ
れます.@samp{_AR}変数でこれに優先することが可能です.これは,通常C++ 
で使用されます.C++コンパイラには,ライブラリに組み込むすべてのテンプ
レートを生成するために,特殊な呼び出しが必要なものもあります.例えば,
SGI C++コンパイラは,この変数を以下のように設定します.
@example
libmaude_a_AR = $(CXX) -ar -o
@end example

@item maude_LIBADD
@c Extra objects can be added to a @emph{library} using the @samp{_LIBADD}
@c variable.  For instance this should be used for objects determined by
@c @code{configure} (@pxref{A Library}).
@c 
@samp{_LIBADD}変数を使用することで,追加のオブジェクトを@emph{ライブラ
リ}に加えることが可能です.例えばこれは,@code{configure}で決定される
オブジェクトに対して使用すべきです(@pxref{A Library}).

@item maude_LDADD
@c Extra objects can be added to a @emph{program} by listing them in the
@c @samp{_LDADD} variable.  For instance this should be used for objects
@c determined by @code{configure} (@pxref{Linking}).
@c 
@samp{_LDADD}変数に追加のオブジェクトをリストアップすることで,
@emph{プログラム}に加えることが可能です.例えばこれは,
@code{configure}で決定されるオブジェクトに対して使用すべきです
(@pxref{Linking}).

@c @samp{_LDADD} and @samp{_LIBADD} are inappropriate for passing
@c program-specific linker flags (except for @samp{-l}, @samp{-L},
@c @samp{-dlopen} and @samp{-dlpreopen}).  Use the @samp{_LDFLAGS} variable
@c for this purpose.
@c 
(@samp{-l},@samp{-L},@samp{-dlopen},そして@samp{-dlpreopen}以外の)
プログラム特有のリンカフラグを渡すために@samp{_LDADD}と@samp{_LIBADD}
を使用することは不適切です.この目的に対しては,@samp{_LDFLAGS}変数を
使用してください.

@c For instance, if your @file{configure.ac} uses @code{AC_PATH_XTRA}, you
@c could link your program against the X libraries like so:
@c 
例えば,@file{configure.ac}で@code{AC_PATH_XTRA}を使用している場合,X
のライブラリに対してプログラムをリンクするため,以下のようにすることが
可能でしょう.

@example
maude_LDADD = $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS)
@end example

@item maude_LDFLAGS
@c This variable is used to pass extra flags to the link step of a program
@c or a shared library.
@c 
これは,プログラムや共有ライブラリのリンク段階に特別なフラグを渡すため
に使用する変数です.

@item maude_DEPENDENCIES
@c It is also occasionally useful to have a program depend on some other
@c target which is not actually part of that program.  This can be done
@c using the @samp{_DEPENDENCIES} variable.  Each program depends on the
@c contents of such a variable, but no further interpretation is done.
@c 
実際には,プログラムの一部にはならない他のターゲットに依存するプログラ
ムがあることが,役に立つ場合もあります.これは,@samp{_DEPENDENCIES}変
数を使用することで可能になります.それぞれのプログラムは,その変数の内
容に依存しますが,それ以上に解釈されません.

@c If @samp{_DEPENDENCIES} is not supplied, it is computed by Automake.
@c The automatically-assigned value is the contents of @samp{_LDADD} or
@c @samp{_LIBADD}, with most configure substitutions, @samp{-l}, @samp{-L},
@c @samp{-dlopen} and @samp{-dlpreopen} options removed.  The configure
@c substitutions that are left in are only @samp{$(LIBOBJS)} and
@c @samp{$(ALLOCA)}; these are left because it is known that they will not
@c cause an invalid value for @samp{_DEPENDENCIES} to be generated.
@c 
@samp{_DEPENDENCIES}が提供されていない場合,それはAutomakeが考慮します.
自動的に割り当てられる値は@samp{_LDADD}や@samp{_LIBADD}の内容で,ほと
んどのconfigure置換式,@samp{-l},@samp{-L},@samp{-dlopen},
@samp{-dlpreopen},そして@samp{-dlpreopen}オプションは削除されています.
残っているconfigureの置換式は,@samp{$(LIBOBJS)}と@samp{$(ALLOCA)}です.
これらは,生成される@samp{_DEPENDENCIES}に対して無効な値を生成しないこ
とが分かっているので残されます.

@item maude_LINK
@c You can override the linker on a per-program basis.  By default the
@c linker is chosen according to the languages used by the program.  For
@c instance, a program that includes C++ source code would use the C++
@c compiler to link.  The @samp{_LINK} variable must hold the name of a
@c command which can be passed all the @file{.o} file names as arguments.
@c Note that the name of the underlying program is @emph{not} passed to
@c @samp{_LINK}; typically one uses @samp{$@@}:
@c 
プログラムごとを基本として,(デフォルトの)リンカに優先することが可能で
す.デフォルトで,プログラムで使用されている言語によってリンカは選択さ
れます.例えば,C++のソースコードを含むプログラムでは,C++コンパイラが
リンクに使用されます.@samp{_LINK}変数は,すべての@file{.o}ファイル名
を引数として渡すことが可能なコマンドの名前を含んでいる必要があります.
基礎となるプログラム名は,@samp{_LINK}に渡され@emph{ない}ことに注意し
てください.通常は@samp{$@@}を使用します.

@example
maude_LINK = $(CCLD) -magic -o $@@
@end example

@item maude_CCASFLAGS
@itemx maude_CFLAGS
@itemx maude_CPPFLAGS
@itemx maude_CXXFLAGS
@itemx maude_FFLAGS
@itemx maude_GCJFLAGS
@itemx maude_LFLAGS
@itemx maude_OBJCFLAGS
@itemx maude_RFLAGS
@itemx maude_YFLAGS
@cindex per-target compilation flags, defined
@c Automake allows you to set compilation flags on a per-program (or
@c per-library) basis.  A single source file can be included in several
@c programs, and it will potentially be compiled with different flags for
@c each program.  This works for any language directly supported by
@c Automake.  These @dfn{per-target compilation flags} are
@c @samp{_CCASFLAGS},
@c @samp{_CFLAGS},
@c @samp{_CPPFLAGS},
@c @samp{_CXXFLAGS},
@c @samp{_FFLAGS},
@c @samp{_GCJFLAGS},
@c @samp{_LFLAGS},
@c @samp{_OBJCFLAGS},
@c @samp{_RFLAGS}, and
@c @samp{_YFLAGS}.
@c 
Automakeでは,プログラムごと(またはライブラリごと)を基本として,コンパ
イルフラグを設定することが可能です.単一のソースファイルを複数のプログ
ラムに含めることが可能で,それぞれのプログラムに対して異なるフラグでコ
ンパイルされる可能性もあります.これは,あらゆる言語に対し,直接
Automakeがサポートすることで動作します.これらの@dfn{ターゲットごとの
コンパイルフラグ(per-target compilation flags)}は,@samp{_CCASFLAGS},
@samp{_CFLAGS},@samp{_CPPFLAGS},@samp{_CXXFLAGS},@samp{_FFLAGS},
@samp{_GCJFLAGS},@samp{_LFLAGS},@samp{_OBJCFLAGS},@samp{_RFLAGS},
そして@samp{_YFLAGS}です.

@c When using a per-target compilation flag, Automake will choose a
@c different name for the intermediate object files.  Ordinarily a file
@c like @file{sample.c} will be compiled to produce @file{sample.o}.
@c However, if the program's @samp{_CFLAGS} variable is set, then the
@c object file will be named, for instance, @file{maude-sample.o}.
@c (See also @ref{renamed objects}.)
@c 
ターゲットごとのコンパイルフラグを使用するとき,Automakeは,中間的なオ
ブジェクトファイルに対して異なる名前を選択します.通常,
@file{sample.c}のようなファイルは,コンパイルされて@file{sample.o}が生
成されます.しかし,プログラムの@samp{_CFLAGS}変数を設定した場合,オブ
ジェクトファイルは,例えば@file{maude-sample.o}のように命名されます.
(@ref{renamed objects}も参照して下さい.)

@c In compilations with per-target flags, the ordinary @samp{AM_} form of
@c the flags variable is @emph{not} automatically included in the
@c compilation (however, the user form of the variable @emph{is} included).
@c So for instance, if you want the hypothetical @file{maude} compilations
@c to also use the value of @samp{AM_CFLAGS}, you would need to write:
@c 
ターゲットごとにフラグを用いてコンパイルする際は,通常の@samp{AM_}形式
のフラグ変数は自動的にコンパイルに組み込まれ@emph{ません}(しかし,ユー
ザ形式の変数は組み込まれ@emph{ます}).そのため,例えば,
@samp{AM_CFLAGS}の変数も使用して@file{maude}のコンパイルを行なうと仮定
すると,以下のように書く必要があります.

@example
maude_CFLAGS = @dots{} your flags @dots{} $(AM_CFLAGS)
@end example


@item maude_SHORTNAME
@c On some platforms the allowable file names are very short.  In order to
@c support these systems and per-target compilation flags at the same
@c time, Automake allows you to set a ``short name'' which will influence
@c how intermediate object files are named.  For instance, in the following
@c example,
@c 
利用可能なファイル名が非常に短いプラットフォームもあります.これらのシ
ステムと,ターゲットごとのコンパイルフラグを同時にサポートするために,
Automakeでは,中間的なオブジェクトファイルの命名方法に影響する``短い名
前''を設定することが可能です.例えば,以下の例のようにします.

@example
bin_PROGRAMS = maude
maude_CPPFLAGS = -DSOMEFLAG
maude_SHORTNAME = m
maude_SOURCES = sample.c @dots{}
@end example

@noindent
@c the object file would be named @file{m-sample.o} rather than
@c @file{maude-sample.o}.
@c 
オブジェクトファイルは@file{maude-sample.o}ではなく@file{m-sample.o}と
命名されます.

@c This facility is rarely needed in practice,
@c and we recommend avoiding it until you find it is required.
@c 
この機能は,実行上滅多に必要になりませんし,要求されていることが分かる
まで使用を避けることを推奨します.
@end table

@node Default _SOURCES
@c @section Default @code{_SOURCES}
@section デフォルトの@code{_SOURCES}

@vindex _SOURCES
@vindex SOURCES
@cindex @code{_SOURCES}, default
@cindex default @code{_SOURCES}

@c @code{_SOURCES} variables are used to specify source files of programs
@c (@pxref{A Program}), libraries (@pxref{A Library}), and Libtool
@c libraries (@pxref{A Shared Library}).
@c 
@code{_SOURCES}変数は,プログラム(@pxref{A Program}),ライブラリ
(@pxref{A Library}),そしてLibtoolライブラリ(@pxref{A Shared Library}) 
のソースファイルを指定するために使用します.

@c When no such variable is specified for a target, Automake will define
@c one itself.  The default is to compile a single C file whose base name
@c is the name of the target itself, with any extension replaced by
@c @file{.c}.  (Defaulting to C is terrible but we are stuck with it for
@c historical reasons.)
@c 
そのような変数がターゲットに対して指定されていない場合,Automakeは独自
に定義します.デフォルトは,コンパイルする単一のCファイルで,その名前
はターゲット自身の名前を元にしていて,拡張子を@file{.c}に置換したもの
です.(Cのデフォルトは危険ですが,我々は歴史的な理由で身動きがとれなく
なっています.)

@c For example if you have the following somewhere in your
@c @file{Makefile.am} with no corresponding @samp{libfoo_a_SOURCES}:
@c 
例えば,以下のような@file{Makefile.am}があって,対応する
@samp{libfoo_a_SOURCES}が無い場合を考えます.

@example
lib_LIBRARIES = libfoo.a sub/libc++.a
@end example

@noindent
@c @file{libfoo.a} will be built using a default source file named
@c @file{libfoo.c}, and @file{sub/libc++.a} will be built from
@c @file{sub/libc++.c}.  (In older versions @file{sub/libc++.a}
@c would be built from @file{sub_libc___a.c}, i.e., the default source
@c was the canonized name of the target, with @file{.c} appended.
@c We believe the new behavior is more sensible, but for backward
@c compatibility automake will use the old name if a file or a rule
@c with that name exist.)
@c 
@file{libfoo.a}はデフォルトのソースファイル名@file{libfoo.c}を使用して
ビルドされ,@file{sub/libc++.a}は@file{sub/libc++.c}からビルドされます.
(より古いバージョンでは,@file{sub/libc++.a}は@file{sub_libc___a.c}か
ら,すなわちデフォルトのソースはターゲットの標準的な名前に@file{.c}を
追加したものでした.我々は,新しい動作はより賢明だと信じていますが,後
方互換性として,その名前のファイルやルールが存在する場合,automakeは古
い名前を使用します.)

@cindex @code{check_PROGRAMS} example
@vindex check_PROGRAMS
@c Default sources are mainly useful in test suites, when building many
@c tests programs each from a single source.  For instance in
@c 
デフォルトのソースは,たくさんのテストプログラムをそれぞれ単一のソース
からビルドする,テストスイートで主に役に立ちます.例えば以下のようにし
ます.

@example
check_PROGRAMS = test1 test2 test3
@end example

@noindent
@c @file{test1}, @file{test2}, and @file{test3} will be built
@c from @file{test1.c}, @file{test2.c}, and @file{test3.c}.
@c 
@file{test1},@file{test2},そして@file{test3}は,それぞれ
@file{test1.c},@file{test2.c},そして@file{test3.c}からビルドされます.

@cindex Libtool modules, default source example
@cindex default source, Libtool modules example
@c Another case where is this convenient is building many Libtool modules
@c (@file{moduleN.la}), each defined in its own file (@file{moduleN.c}).
@c 
これが便利になるもう一つの状況は,独自のファイル(@file{moduleN.c})で定
義されている多くのLibtoolモジュール(@file{moduleN.la})をビルドするとき
です.

@example
AM_LDFLAGS = -module
lib_LTLIBRARIES = module1.la module2.la module3.la
@end example

@cindex empty @code{_SOURCES}
@cindex @code{_SOURCES}, empty
@c Finally, there is one situation where this default source computation
@c needs to be avoided: when a target should not be built from sources.
@c We already saw such an example in @ref{true}; this happens when all
@c the constituents of a target have already been compiled and need just
@c to be combined using a @code{_LDADD} variable.  Then it is necessary
@c to define an empty @code{_SOURCES} variable, so that automake does not
@c compute a default.
@c 
おしまいに,このデフォルトのソースを求めることを避ける必要がある状況が
一つあります.ターゲットがソースからビルドされないときです.我々は
@ref{true}でそのような例を見てきました.これは,ターゲットのすべての構
成要素が既にコンパイルされていて,単に@code{_LDADD}変数を使用して結合
する必要があるときに生じます.そして,automakeがデフォルトを求めないよ
うに空の@code{_SOURCES}変数を定義する必要があります.

@example
bin_PROGRAMS = target
target_SOURCES =
target_LDADD = libmain.a libmisc.a
@end example

@node LIBOBJS
@c @section Special handling for LIBOBJS and ALLOCA
@section LIBOBJSとALLOCAに対する特別扱い

@cindex @code{LIBOBJS}, special handling
@cindex @code{ALLOCA}, special handling

@c Automake explicitly recognizes the use of @code{$(LIBOBJS)} and
@c @code{$(ALLOCA)}, and uses this information, plus the list of
@c @code{LIBOBJS} files derived from @file{configure.ac} to automatically
@c include the appropriate source files in the distribution (@pxref{Dist}).
@c These source files are also automatically handled in the
@c dependency-tracking scheme; see @xref{Dependencies}.
@c 
Automakeは,@code{$(LIBOBJS)}と@code{$(ALLOCA)}を使用していることを明
示的に認識し,そしてこの情報を使用し,配布物に適切なソースファイルを自
動的に含めるため(@pxref{Dist}),@file{configure.ac}から派生される
@code{LIBOBJS}ファイルのリストに追加します.これらのソースファイルは,
依存性追跡でも自動的に処理されます.@xref{Dependencies}.

@c @code{$(LIBOBJS)} and @code{$(ALLOCA)} are specially recognized in any
@c @samp{_LDADD} or @samp{_LIBADD} variable.
@c 
@code{$(LIBOBJS)}と@code{$(ALLOCA)}は,あらゆる@samp{_LDADD}や
@samp{_LIBADD}で特別に認識されます.


@node Program variables
@c @section Variables used when building a program
@section プログラムビルド時に使用される変数

@c Occasionally it is useful to know which @file{Makefile} variables
@c Automake uses for compilations; for instance you might need to do your
@c own compilation in some special cases.
@c 
Automakeがコンパイルに使用する@file{Makefile}変数を知ることが役に立ち
つこともあります.例えば,特別な状況では,自分でコンパイルをする必要が
あるかもしれません.

@c Some variables are inherited from Autoconf; these are @code{CC},
@c @code{CFLAGS}, @code{CPPFLAGS}, @code{DEFS}, @code{LDFLAGS}, and
@c @code{LIBS}.
@c 
Autoconfから継承される変数もあります.これらは@code{CC},@code{CFLAGS},
@code{CPPFLAGS},@code{DEFS},@code{LDFLAGS},そして@code{LIBS}です.
@vindex CC
@vindex CFLAGS
@vindex CPPFLAGS
@vindex DEFS
@vindex LDFLAGS
@vindex LIBS

@c There are some additional variables which Automake itself defines:
@c 
Automake自身が定義する追加の変数もあります.

@vtable @code
@item AM_CPPFLAGS
@c The contents of this variable are passed to every compilation which invokes
@c the C preprocessor; it is a list of arguments to the preprocessor.  For
@c instance, @samp{-I} and @samp{-D} options should be listed here.
@c 
この変数の内容は,Cプリプロセッサを呼び出すコンパイルで毎回渡されます.
それはプリプロセッサへの引数リストです.例えば,@samp{-I}と@samp{-D}オ
プションは,ここにリストアップすべきです.

@c Automake already provides some @samp{-I} options automatically.  In
@c particular it generates @samp{-I$(srcdir)}, @samp{-I.}, and a @samp{-I}
@c pointing to the directory holding @file{config.h} (if you've used
@c @code{AC_CONFIG_HEADERS} or @code{AM_CONFIG_HEADER}).  You can disable
@c the default @samp{-I} options using the @samp{nostdinc} option.
@c 
Automakeは,すでに@samp{-I}オプションを自動的に提供しています.特に,
@samp{-I$(srcdir)},@samp{-I.},そして(@code{AC_CONFIG_HEADERS}や
@code{AM_CONFIG_HEADER}を使用している場合は)@file{config.h}があるディ
レクトリを示す@samp{-I}を生成します.@samp{nostdinc}オプションを使用す
ることで,デフォルトの@samp{-I}オプションを利用不可能にすることが可能
です.

@c @code{AM_CPPFLAGS} is ignored in preference to a per-executable (or
@c per-library) @code{_CPPFLAGS} variable if it is defined.
@c 
実行形式ごと(またはライブラリごと)に@code{_CPPFLAGS}変数が定義されてい
る場合,それを優先するので,@code{AM_CPPFLAGS}は無視されます.

@item INCLUDES
@c This does the same job as @samp{AM_CPPFLAGS} (or any per-target
@c @samp{_CPPFLAGS} variable if it is used).  It is an older name for the
@c same functionality.  This variable is deprecated; we suggest using
@c @samp{AM_CPPFLAGS} and per-target @samp{_CPPFLAGS} instead.
@c 
これは,@samp{AM_CPPFLAGS}と同じ仕事をします(または,ターゲットごとに
@samp{_CPPFLAGS}が使用されている場合と同じです).それは同じ機能に対す
る古い名前です.この変数の使用には反対します.我々は,代わりに
@samp{AM_CPPFLAGS}とターゲットごとの@samp{_CPPFLAGS}の使用を勧めます.

@item AM_CFLAGS
@c This is the variable which the @file{Makefile.am} author can use to pass
@c in additional C compiler flags.  It is more fully documented elsewhere.
@c In some situations, this is not used, in preference to the
@c per-executable (or per-library) @code{_CFLAGS}.
@c 
これは,@file{Makefile.am}の著者が,追加のCコンパイラフラグを渡すため
に使用することが可能な変数です.その完全な説明はどこかにあるでしょう.
状況によっては,実行形式ごと(またはライブラリごと)の@code{_CFLAGS}が優
先され,これは使用されません.

@item COMPILE
@c This is the command used to actually compile a C source file.  The
@c filename is appended to form the complete command line.
@c 
これはCソースファイルをコンパイルするために実際に使用されるコマンドで
す.完全なコマンドラインを構成するために,ファイル名が追加されます.

@item AM_LDFLAGS
@c This is the variable which the @file{Makefile.am} author can use to pass
@c in additional linker flags.  In some situations, this is not used, in
@c preference to the per-executable (or per-library) @code{_LDFLAGS}.
@c 
これは,@file{Makefile.am}の著者が,追加のリンカフラグを渡すために使用
することが可能な変数です.状況によっては,実行形式ごと(またはライブラ
リごと)の@code{_LDFLAGS}が優先され,これは使用されません.

@item LINK
@c This is the command used to actually link a C program.  It already
@c includes @samp{-o $@@} and the usual variable references (for instance,
@c @code{CFLAGS}); it takes as ``arguments'' the names of the object files
@c and libraries to link in.
@c 
これはCプログラムをリンクするために実際に使用されるコマンドです.それ
にはすでに,@samp{-o $@@}と通常参照される変数(例えば,@code{CFLAGS})が
含まれています.それは,リンクされるオブジェクトファイルとライブラリの
名前を``引数''として受けとります.
@end vtable


@node Yacc and Lex
@c @section Yacc and Lex support
@section YaccとLexのサポート

@c Automake has somewhat idiosyncratic support for Yacc and Lex.
@c 
AutomakeはYaccとLexに対して幾分特異なサポートを行ないます.

@c Automake assumes that the @file{.c} file generated by @code{yacc} (or
@c @code{lex}) should be named using the basename of the input file.  That
@c is, for a yacc source file @file{foo.y}, Automake will cause the
@c intermediate file to be named @file{foo.c} (as opposed to
@c @file{y.tab.c}, which is more traditional).
@c 
Automakeは,@code{yacc}(あるいは@code{lex})によって生成された@file{.c}
ファイルが,入力ファイルのベース名を使用して命名されていると仮定します.
すなわち,yaccソースファイル@file{foo.y}に対して,Automakeは中間ファイ
ルを(より伝統的な@file{y.tab.c}ではなく)@file{foo.c}と命名します.

@c The extension of a yacc source file is used to determine the extension
@c of the resulting @samp{C} or @samp{C++} file.  Files with the extension
@c @samp{.y} will be turned into @samp{.c} files; likewise, @samp{.yy} will
@c become @samp{.cc}; @samp{.y++}, @samp{c++}; and @samp{.yxx},
@c @samp{.cxx}.
@c 
yaccソースファイルの拡張子は,結果として生じる@samp{C}あるいは
@samp{C++} ファイルの拡張子を決定するために使用されます.ファイルの拡
張子が@samp{.y}の場合は@samp{.c}になります.同様に@samp{.yy}は
@samp{.cc}に,@samp{.y++}は@samp{c++}に,そして@samp{.yxx}は
@samp{.cxx}になります.

@c Likewise, lex source files can be used to generate @samp{C} or
@c @samp{C++}; the extensions @samp{.l}, @samp{.ll}, @samp{.l++}, and
@c @samp{.lxx} are recognized.
@c 
同様に,lexソースファイルは,@samp{C}や@samp{C++}を生成するために使用
することが可能です.拡張子の@samp{.l},@samp{.ll},@samp{.l++},そして
@samp{.lxx}が認識されます.

@c You should never explicitly mention the intermediate (@samp{C} or
@c @samp{C++}) file in any @samp{SOURCES} variable; only list the source
@c file.
@c 
あらゆる@samp{SOURCES}変数に,(@samp{C}や@samp{C++}の)中間的なファイル
を明示的に書いてはいけません.ソースファイルだけをリストアップします.

@c The intermediate files generated by @code{yacc} (or @code{lex}) will be
@c included in any distribution that is made.  That way the user doesn't
@c need to have @code{yacc} or @code{lex}.
@c 
@code{yacc}(あるいは@code{lex})によって生成さる中間的なファイルは,作
成されるすべての配布物に含められます.そのためユーザが@code{yacc}や
@code{lex}を持っている必要がありません.

@c If a @code{yacc} source file is seen, then your @file{configure.ac} must
@c define the variable @samp{YACC}.  This is most easily done by invoking
@c the macro @samp{AC_PROG_YACC} (@pxref{Particular Programs, , Particular
@c Program Checks, autoconf, The Autoconf Manual}).
@c 
@code{yacc}ソースファイルが見つかった場合,@file{configure.ac}で変数
@samp{YACC}を定義する必要があります.これは,マクロ@samp{AC_PROG_YACC}
を呼び出すことで最も容易に行なえます(@pxref{Particular Programs, ,
Particular Program Checks, autoconf, The Autoconf Manual}).

@c When @code{yacc} is invoked, it is passed @samp{YFLAGS} and
@c @samp{AM_YFLAGS}.  The former is a user variable and the latter is
@c intended for the @file{Makefile.am} author.
@c 
@code{yacc}が呼び出された時,@samp{YFLAGS}と@samp{AM_YFLAGS}フラグが渡
されます.前者はユーザ変数で,後者は@file{Makefile.am}の著者のためのも
のです.

@c @samp{AM_YFLAGS} is usually used to pass the @code{-d} option to
@c @code{yacc}.  Automake knows what this means and will automatically
@c adjust its rules to update and distribute the header file built by
@c @code{yacc -d}.  What Automake cannot guess, though, is where this
@c header will be used: it is up to you to ensure the header gets built
@c before it is first used.  Typically this is necessary in order for
@c dependency tracking to work when the header is included by another
@c file.  The common solution is listing the header file in
@c @code{BUILT_SOURCES} (@pxref{Sources}) as follows.
@c 
@samp{AM_YFLAGS}は通常,@code{-d}オプションを@code{yacc}に渡すとき使用
されます.Automakeはこれが意味するところを知っていて,@code{yacc -d}で
ビルドされるヘッダファイルの更新と配布のルールを,自動的に調整します.
しかし,Automakeが分からないものは,このヘッダが使用される場所です.ヘッ
ダが最初に使用される前にヘッダをビルドしておくことはあなたの責任です.
通常これは,ヘッダが他のファイルからインクルードされているとき,依存性
の追跡が動作するために必要となります.一般的な解決策は,ヘッダファイル
を以下のように@code{BUILT_SOURCES} (@pxref{Sources})にリストアップする
ことです.

@example
BUILT_SOURCES = parser.h
AM_YFLAGS = -d
bin_PROGRAMS = foo
foo_SOURCES = @dots{} parser.y @dots{}
@end example

@c If a @code{lex} source file is seen, then your @file{configure.ac}
@c must define the variable @samp{LEX}.  You can use @samp{AC_PROG_LEX}
@c to do this (@pxref{Particular Programs, , Particular Program Checks,
@c autoconf, The Autoconf Manual}), but using @code{AM_PROG_LEX} macro
@c (@pxref{Macros}) is recommended.
@c 
同様に,@code{lex}ソースファイルがある場合,@file{configure.ac}で変数
@samp{LEX}を定義する必要があります.こうするために@samp{AC_PROG_LEX}を
使用することが可能ですが(@pxref{Particular Programs, , Particular
Program Checks, autoconf, The Autoconf Manual}),@code{AM_PROG_LEX}マ
クロ(@pxref{Macros})の使用を推奨します.

@c When @code{lex} is invoked, it is passed @samp{LFLAGS} and
@c @samp{AM_LFLAGS}.  The former is a user variable and the latter is
@c intended for the @file{Makefile.am} author.
@c 
@code{lex}が呼び出されたとき,@samp{LFLAGS}と@samp{AM_LFLAGS}フラグが
渡されます.前者はユーザ変数で,後者は@file{Makefile.am}の著者のための
ものです.



@cindex ylwrap
@cindex yacc, multiple parsers
@cindex Multiple yacc parsers
@cindex Multiple lex lexers
@cindex lex, multiple lexers


@c Automake makes it possible to include multiple @code{yacc} (or
@c @code{lex}) source files in a single program.  When there is more than
@c one distinct @code{yacc} (or @code{lex}) source file in a directory,
@c Automake uses a small program called @code{ylwrap} to run @code{yacc}
@c (or @code{lex}) in a subdirectory.  This is necessary because yacc's
@c output filename is fixed, and a parallel make could conceivably invoke
@c more than one instance of @code{yacc} simultaneously.  The @code{ylwrap}
@c program is distributed with Automake.  It should appear in the directory
@c specified by @samp{AC_CONFIG_AUX_DIR} (@pxref{Input, , Finding
@c `configure' Input, autoconf, The Autoconf Manual}), or the current
@c directory if that macro is not used in @file{configure.ac}.
@c 
Automakeで,一つのプログラムに複数の@code{yacc}(または@code{lex})ソー
スファイルを含めることが可能になります.ディレクトリに一つ以上の異なる
@code{yacc}(または@code{lex})のソースファイルがあるとき,Automakeは,
サブディレクトリで@code{yacc}(または@code{lex})を実行するために,
@code{ylwrap}と呼ばれる小さいプログラムを使用します.これが必要になる
のは,yaccの出力ファイル名が固定されていて,並列的なmakeで@code{yacc} 
の一つ以上のインスタンスを同時に呼び出す可能性があるためです.
@code{ylwrap}プログラムは,Automakeと一緒に配布されます.それは
@samp{AC_CONFIG_AUX_DIR}が指定するディレクトリ (@pxref{Input, ,
Finding `configure' Input, autoconf, The Autoconf Manual}),または,そ
のマクロが@file{configure.ac}で使用されていない場合はカレントディレク
トリにあります.

@c For @code{yacc}, simply managing locking is insufficient.  The output of
@c @code{yacc} always uses the same symbol names internally, so it isn't
@c possible to link two @code{yacc} parsers into the same executable.
@c 
@code{yacc}に対しては,簡単なロックでの管理は不十分です.@code{yacc}の
出力は,内部で常に同じシンボル名を使うので,同じ実行形式の中に二つの
@code{yacc}パーサーをリンクするは不可能です.

@c We recommend using the following renaming hack used in @code{gdb}:
@c 
@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
#define yyname   c_yyname
#define yyrule   c_yyrule
@end example

@c For each define, replace the @samp{c_} prefix with whatever you like.
@c These defines work for @code{bison}, @code{byacc}, and traditional
@c @code{yacc}s.  If you find a parser generator that uses a symbol not
@c covered here, please report the new name so it can be added to the list.
@c 
それぞれの定義に対して,@samp{c_}接頭辞は好みのものに置き換えて下さい.
これらは,@code{bison},@code{byacc},そして伝統的な@code{yacc}に対す
る動作を定義します.パーサジェネレータが,ここでカバーされていないシン
ボルを使用していることが分かった場合,リストに加えることができるように,
新しい名前を報告してください.


@node C++ Support
@c @section C++ Support
@section C++のサポート

@cindex C++ support
@cindex Support for C++

@c Automake includes full support for C++.
@c 
Automakeには,C++に対する完全なサポートが含まれています.

@c Any package including C++ code must define the output variable
@c @samp{CXX} in @file{configure.ac}; the simplest way to do this is to use
@c the @code{AC_PROG_CXX} macro (@pxref{Particular Programs, , Particular
@c Program Checks, autoconf, The Autoconf Manual}).
@c 
C++コードを含んでいるすべてのパッケージでは,@file{configure.ac}で出力
変数@samp{CXX}を定義する必要があります.これを行う最も単純な方法は,
@code{AC_PROG_CXX}マクロを使用することです(@pxref{Particular Programs,
, Particular Program Checks, autoconf, The Autoconf Manual}).

@c A few additional variables are defined when a C++ source file is seen:
@c 
C++ソースファイルがあるとき,少しだけ追加変数が定義されます.

@vtable @code
@item CXX
@c The name of the C++ compiler.
@c 
C++コンパイラの名前です.

@item CXXFLAGS
@c Any flags to pass to the C++ compiler.
@c 
C++コンパイラに渡すすべてのフラグです.

@item AM_CXXFLAGS
@c The maintainer's variant of @code{CXXFLAGS}.
@c 
管理者のための@code{CXXFLAGS}です.

@item CXXCOMPILE
@c The command used to actually compile a C++ source file.  The file name
@c is appended to form the complete command line.
@c 
C++ソースファイルを実際にコンパイルするために使用されるコマンドです.
完全なコマンドラインを構成するためにファイル名が追加されます.

@item CXXLINK
@c The command used to actually link a C++ program.
@c 
実際にC++プログラムをリンクするコマンドです.
@end vtable


@node Assembly Support
@c @section Assembly Support
@section アセンブラのサポート

@c Automake includes some support for assembly code.
@c 
Automakeは,アセンブラコードに対するサポートも含んでいます.

@c The variable @code{CCAS} holds the name of the compiler used to build
@c assembly code.  This compiler must work a bit like a C compiler; in
@c particular it must accept @samp{-c} and @samp{-o}.  The value of
@c @code{CCASFLAGS} is passed to the compilation.
@c 
変数@code{CCAS}には,アセンブラコードをビルドするために使用するコンパ
イラ名が保持されています.このコンパイラは,Cコンパイラにちょっと似て
いる動作をする必要があります.特に,それは@samp{-c}と@samp{-o}を受け入
れる必要があります.@code{CCASFLAGS}の値はコンパイラに渡されます.
@vindex CCAS
@vindex CCASFLAGS

@c You are required to set @code{CCAS} and @code{CCASFLAGS} via
@c @file{configure.ac}.  The autoconf macro @code{AM_PROG_AS} will do this
@c for you.  Unless they are already set, it simply sets @code{CCAS} to the
@c C compiler and @code{CCASFLAGS} to the C compiler flags.
@c 
@file{configure.ac}で@code{CCAS}と@code{CCASFLAGS}を設定する必要があり
ます.autoconfマクロの@code{AM_PROG_AS}でこれを行ないます.前もって設
定されていない場合は,@code{CCAS}をCコンパイラに, @code{CCASFLAGS}をC
コンパイラフラグに,単純に設定します.

@c Only the suffixes @samp{.s} and @samp{.S} are recognized by
@c @code{automake} as being files containing assembly code.
@c 
接尾子の@samp{.s}と@samp{.S}だけがアセンブリコードを含んでいるファイル
だと@code{automake}で認識されます.


@node Fortran 77 Support
@comment  node-name,  next,  previous,  up
@c @section Fortran 77 Support
@section Fortran 77のサポート

@cindex Fortran 77 support
@cindex Support for Fortran 77

@c Automake includes full support for Fortran 77.
@c 
Automakeには,Fortran 77に対する完全なサポートが含まれています.

@c Any package including Fortran 77 code must define the output variable
@c @samp{F77} in @file{configure.ac}; the simplest way to do this is to use
@c the @code{AC_PROG_F77} macro (@pxref{Particular Programs, , Particular
@c Program Checks, autoconf, The Autoconf Manual}).
@c 
Fortran 77コードを含むパッケージでは,@file{configure.ac}で出力変数
@samp{F77}を定義する必要があります.こうするための最も簡単な方法は
@code{AC_PROG_F77}マクロを使用することです(@pxref{Particular Programs,
, Particular Program Checks, autoconf, The Autoconf Manual}).

@c A few additional variables are defined when a Fortran 77 source file is
@c seen:
@c 
Fortran 77ソースファイルが見つかるとき,追加変数がいくつか定義されます.

@vtable @code

@item F77
@c The name of the Fortran 77 compiler.
@c 
Fortran 77コンパイラの名前です.

@item FFLAGS
@c Any flags to pass to the Fortran 77 compiler.
@c 
Fortran 77コンパイラに渡す,すべてのフラグです.

@item AM_FFLAGS
@c The maintainer's variant of @code{FFLAGS}.
@c 
管理者のための@code{FFLAGS}です.

@item RFLAGS
@c Any flags to pass to the Ratfor compiler.
@c 
Ratforコンパイラに渡す,すべてのフラグです.

@item AM_RFLAGS
@c The maintainer's variant of @code{RFLAGS}.
@c 
管理者のための@code{RFLAGS}です.

@item F77COMPILE
@c The command used to actually compile a Fortran 77 source file.  The file
@c name is appended to form the complete command line.
@c 
実際にFortran 77ソースファイルをコンパイルするコマンドです.完全なコマ
ンドラインを構成するために,ファイル名が追加されます.

@item FLINK
@c The command used to actually link a pure Fortran 77 program or shared
@c library.
@c 
実際に純粋なFortran 77プログラムあるいは共有ライブラリをリンクするコマ
ンドです.

@end vtable

@c Automake can handle preprocessing Fortran 77 and Ratfor source files in
@c addition to compiling them@footnote{Much, if not most, of the
@c information in the following sections pertaining to preprocessing
@c Fortran 77 programs was taken almost verbatim from @ref{Catalogue of
@c Rules, , Catalogue of Rules, make, The GNU Make Manual}.}.  Automake
@c also contains some support for creating programs and shared libraries
@c that are a mixture of Fortran 77 and other languages (@pxref{Mixing
@c Fortran 77 With C and C++}).
@c 
さらにAutomakeは,コンパイルするためにFortran 77とRatforソースファイル
のプリプロセス処理を行なうことが可能です@footnote{以下のセクションにあ
るFortran 77プログラムのプリプロセスに関する情報について,大部分ではあ
りませんが,多くのものを@ref{Catalogue of Rules, , Catalogue of Rules,
make, The GNU Make Manual}からほとんどそのまま持ってきています.}.
Automake には,Fortran 77と他の言葉が混合しているプログラムと共有ライ
ブラリを作成するためのサポートも含まれています(@pxref{Mixing Fortran
77 With C and C++}).

@c These issues are covered in the following sections.
@c 
これらの問題は次のセクションで述べます.

@menu
* Preprocessing Fortran 77::    Preprocessing Fortran 77 sources
* Compiling Fortran 77 Files::  Compiling Fortran 77 sources
* Mixing Fortran 77 With C and C++::  Mixing Fortran 77 With C and C++
@end menu


@node Preprocessing Fortran 77
@comment  node-name,  next,  previous,  up
@c @subsection Preprocessing Fortran 77
@subsection Fortran 77のプリプロセス

@cindex Preprocessing Fortran 77
@cindex Fortran 77, Preprocessing
@cindex Ratfor programs

@c @file{N.f} is made automatically from @file{N.F} or @file{N.r}.  This
@c rule runs just the preprocessor to convert a preprocessable Fortran 77
@c or Ratfor source file into a strict Fortran 77 source file.  The precise
@c command used is as follows:
@c 
@file{N.f}は自動的に@file{N.F}あるいは@file{N.r}から作成されます.この
ルールは,プリプロセス可能なFortran 77やRatforソースファイルを,厳密な
Fortran 77ソースファイルに変換するためだけにプリプロセッサを走らせます.
使用される正確なコマンドは以下のようになります.

@table @file

@item .F
@code{$(F77) -F $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)}

@item .r
@code{$(F77) -F $(AM_FFLAGS) $(FFLAGS) $(AM_RFLAGS) $(RFLAGS)}

@end table


@node Compiling Fortran 77 Files
@comment  node-name,  next,  previous,  up
@c @subsection Compiling Fortran 77 Files
@subsection Fortran 77ファイルのコンパイル

@c @file{N.o} is made automatically from @file{N.f}, @file{N.F} or
@c @file{N.r} by running the Fortran 77 compiler.  The precise command used
@c is as follows:
@c 
@file{N.o}は,Fortran 77を実行することによって@file{N.f},@file{N.F},
または@file{N.r}から自動的に作成されます.使用される正確なコマンドは以
下のようになります.

@table @file

@item .f
@code{$(F77) -c $(AM_FFLAGS) $(FFLAGS)}

@item .F
@code{$(F77) -c $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)}

@item .r
@code{$(F77) -c $(AM_FFLAGS) $(FFLAGS) $(AM_RFLAGS) $(RFLAGS)}

@end table


@node Mixing Fortran 77 With C and C++
@comment  node-name,  next,  previous,  up
@c @subsection Mixing Fortran 77 With C and C++
@subsection CとC++と,Fortran 77の混在

@cindex Fortran 77, mixing with C and C++
@cindex Mixing Fortran 77 with C and C++
@cindex Linking Fortran 77 with C and C++
@cindex cfortran
@cindex Mixing Fortran 77 with C and/or C++

@c Automake currently provides @emph{limited} support for creating programs
@c and shared libraries that are a mixture of Fortran 77 and C and/or C++.
@c However, there are many other issues related to mixing Fortran 77 with
@c other languages that are @emph{not} (currently) handled by Automake, but
@c that are handled by other packages@footnote{For example,
@c @uref{http://www-zeus.desy.de/~burow/cfortran/, the cfortran package}
@c addresses all of these inter-language issues, and runs under nearly all
@c Fortran 77, C and C++ compilers on nearly all platforms.  However,
@c @code{cfortran} is not yet Free Software, but it will be in the next
@c major release.}.
@c 
Automakeは現在,Fortran 77とCそして/またはC++が混在しているプログラム
と共有ライブラリを作成するため,@emph{限定された}サポートを提供してい
ます.しかし,(現在は)Automakeによって処理され@emph{ません}が,他のパッ
ケージ@footnote{例えば,
@uref{http://www-zeus.desy.de/~burow/cfortran/, the cfortran package}
は,これらすべての言語間の問題を扱い,ほとんどすべてのプラットホームの,
ほとんどすべてのFortran 77,C,そしてC++コンパイラで動作します.しかし
ながら,@code{cfortran}はまだフリーソフトウェアではありませんが,次の
メジャーリリースでそうなるでしょう.}で処理される,Fortran 77と他の言
葉との混在に関連して,多くの問題が発生しています.

@page
@c Automake can help in two ways:
@c 
Automakeは二つの方法でそれを助けることが可能です.

@enumerate
@item
@c Automatic selection of the linker depending on which combinations of
@c source code.
@c 
ソースコードの組み合わせに依存したリンカの自動的な選択.

@item
@c Automatic selection of the appropriate linker flags (e.g. @samp{-L} and
@c @samp{-l}) to pass to the automatically selected linker in order to link
@c in the appropriate Fortran 77 intrinsic and run-time libraries.
@c 
適切なFortran 77のイントリンシックとランタイムライブラリにリンクするた
めに,自動的に選択されたリンカに渡す適切なリンカフラグ(例えば@samp{-L}
と@samp{-l})の自動的な選択.

@cindex FLIBS, defined
@c These extra Fortran 77 linker flags are supplied in the output variable
@c @code{FLIBS} by the @code{AC_F77_LIBRARY_LDFLAGS} Autoconf macro
@c supplied with newer versions of Autoconf (Autoconf version 2.13 and
@c later).  @xref{Fortran 77 Compiler Characteristics, , , autoconf, The
@c Autoconf}.
@c 
これらの追加されたFortran 77リンカフラグは,Autoconf(Autoconfバージョ
ン2.13やそれ以降)の新しいバージョンで供給された,
@code{AC_F77_LIBRARY_LDFLAGS}というAutoconfマクロでの出力変数
@code{FLIBS}で提供されます.@xref{Fortran 77 Compiler Characteristics,
, , autoconf, The Autoconf}.
@end enumerate

@c If Automake detects that a program or shared library (as mentioned in
@c some @code{_PROGRAMS} or @code{_LTLIBRARIES} primary) contains source
@c code that is a mixture of Fortran 77 and C and/or C++, then it requires
@c that the macro @code{AC_F77_LIBRARY_LDFLAGS} be called in
@c @file{configure.ac}, and that either @code{$(FLIBS)}
@c appear in the appropriate @code{_LDADD} (for programs) or @code{_LIBADD}
@c (for shared libraries) variables.  It is the responsibility of the
@c person writing the @file{Makefile.am} to make sure that @code{$(FLIBS)}
@c appears in the appropriate @code{_LDADD} or
@c @code{_LIBADD} variable.
@c 
(@code{_PROGRAMS}や@code{_LTLIBRARIES}プライマリで記述されているような) 
プログラムや共有ライブラリが,Fortran 77と,Cそして/またはC++が混合す
るソースコードを含んでいることをAutomakeが検出した場合,
@code{AC_F77_LIBRARY_LDFLAGS}マクロを@file{configure.ac}で呼び出し,
@code{$(FLIBS)}が,適切な(プログラムに対する)@code{_LDADD}や,(共有ラ
イブラリに対する)@code{_LIBADD}変数のいずれかで書かれていることを要求
します.@code{$(FLIBS)}が適切な@code{_LDADD}や@code{_LIBADD}変数に書か
れていることを確かめるのは,@file{Makefile.am}を書いている人の責任です.

@cindex Mixed language example
@cindex Example, mixed language

@c For example, consider the following @file{Makefile.am}:
@c 
例えば,以下の@file{Makefile.am}を考えます.

@example
bin_PROGRAMS = foo
foo_SOURCES  = main.cc foo.f
foo_LDADD    = libfoo.la $(FLIBS)

pkglib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES  = bar.f baz.c zardoz.cc
libfoo_la_LIBADD   = $(FLIBS)
@end example

@c In this case, Automake will insist that @code{AC_F77_LIBRARY_LDFLAGS}
@c is mentioned in @file{configure.ac}.  Also, if @code{$(FLIBS)} hadn't
@c been mentioned in @code{foo_LDADD} and @code{libfoo_la_LIBADD}, then
@c Automake would have issued a warning.
@c 
この状況では,Automakeは,@code{AC_F77_LIBRARY_LDFLAGS}が
@file{configure.ac}で記述されることを強く要求します.また,
@code{$(FLIBS)}が@code{foo_LDADD}と@code{libfoo_la_LIBADD}で記述されて
いない場合も,Automakeは警告を出します.


@page
@menu
* How the Linker is Chosen::    Automatic linker selection
@end menu

@node How the Linker is Chosen
@comment  node-name,  next,  previous,  up
@c @subsubsection How the Linker is Chosen
@subsubsection リンカの選択方法

@cindex Automatic linker selection
@cindex Selecting the linker automatically

@c The following diagram demonstrates under what conditions a particular
@c linker is chosen by Automake.
@c 
Automakeによって特定のリンカが選択される条件を以下の図で明示します.

@c For example, if Fortran 77, C and C++ source code were to be compiled
@c into a program, then the C++ linker will be used.  In this case, if the
@c C or Fortran 77 linkers required any special libraries that weren't
@c included by the C++ linker, then they must be manually added to an
@c @code{_LDADD} or @code{_LIBADD} variable by the user writing the
@c @file{Makefile.am}.
@c 
例えば,Fortran 77,C,そしてC++ソースコードがプログラムにコンパイルさ
れる場合,C++リンカが使用されます.この場合,CあるいはFortran 77リンカ
が,C++リンカに含まれていない特別なライブラリを必要とした場合,
@file{Makefile.am}を書いているユーザが,@code{_LDADD}や@code{_LIBADD} 
変数を手作業で付け加える必要があります.

@example
                     \              Linker
          source      \
           code        \     C        C++     Fortran
     -----------------  +---------+---------+---------+
                        |         |         |         |
     C                  |    x    |         |         |
                        |         |         |         |
                        +---------+---------+---------+
                        |         |         |         |
         C++            |         |    x    |         |
                        |         |         |         |
                        +---------+---------+---------+
                        |         |         |         |
               Fortran  |         |         |    x    |
                        |         |         |         |
                        +---------+---------+---------+
                        |         |         |         |
     C + C++            |         |    x    |         |
                        |         |         |         |
                        +---------+---------+---------+
                        |         |         |         |
     C +       Fortran  |         |         |    x    |
                        |         |         |         |
                        +---------+---------+---------+
                        |         |         |         |
         C++ + Fortran  |         |    x    |         |
                        |         |         |         |
                        +---------+---------+---------+
                        |         |         |         |
     C + C++ + Fortran  |         |    x    |         |
                        |         |         |         |
                        +---------+---------+---------+
@end example

@node Fortran 9x Support
@comment  node-name,  next,  previous,  up
@c @section Fortran 9x Support
@section Fortran 9xのサポート

@cindex Fortran 9x support
@cindex Support for Fortran 9x

@c Automake includes full support for Fortran 9x.
@c 
Automakeには,Fortran 9xに対する完全なサポートが含まれています.

@c Any package including Fortran 9x code must define the output variable
@c @samp{FC} in @file{configure.ac}; the simplest way to do this is to use
@c the @code{AC_PROG_FC} macro (@pxref{Particular Programs, , Particular
@c Program Checks, autoconf, The Autoconf Manual}).
@c 
Fortran 9xコードを含むパッケージでは,@file{configure.ac}で出力変数
@samp{FC}を定義する必要があります.こうするための最も簡単な方法は
@code{AC_PROG_FC}マクロを使用することです(@pxref{Particular Programs,
, Particular Program Checks, autoconf, The Autoconf Manual}).

@c A few additional variables are defined when a Fortran 9x source file is
@c seen:
@c 
Fortran 9xソースファイルが見つかるとき,追加変数がいくつか定義されます.

@vtable @code

@item FC
@c The name of the Fortran 9x compiler.
@c 
Fortran 9xコンパイラの名前です.

@item FCFLAGS
@c Any flags to pass to the Fortran 9x compiler.
@c 
Fortran 9xコンパイラに渡す,すべてのフラグです.

@item AM_FCFLAGS
@c The maintainer's variant of @code{FCFLAGS}.
@c 
管理者のための@code{FCLAGS}です.

@item FCCOMPILE
@c The command used to actually compile a Fortran 9x source file.  The file
@c name is appended to form the complete command line.
@c 
実際にFortran 9xソースファイルをコンパイルするコマンドです.完全なコマ
ンドラインを構成するために,ファイル名が追加されます.

@item FCLINK
@c The command used to actually link a pure Fortran 9x program or shared
@c library.
@c 
実際に純粋なFortran 9xプログラムあるいは共有ライブラリをリンクするコマ
ンドです.

@end vtable

@menu
* Compiling Fortran 9x Files::  Compiling Fortran 9x sources
@end menu

@node Compiling Fortran 9x Files
@comment  node-name,  next,  previous,  up
@c @subsection Compiling Fortran 9x Files
@subsection Fortran 9xファイルのコンパイル

@c @file{N.o} is made automatically from @file{N.f90} or @file{N.f95}
@c by running the Fortran 9x compiler.  The precise command used
@c is as follows:
@c 
@file{N.o}は,Fortran 9xを実行することによって@file{N.f90}または
@file{N.F95}から自動的に作成されます.使用される正確なコマンドは以下の
ようになります.

@table @file

@item .f9x
@code{$(FC) -c $(AM_FCFLAGS) $(FCFLAGS)}

@end table

@node Java Support
@comment  node-name,  next,  previous,  up
@c @section Java Support
@section Javaのサポート

@cindex Java support
@cindex Support for Java

@c Automake includes support for compiled Java, using @code{gcj}, the Java
@c front end to the GNU Compiler Collection.
@c 
Automakeには,GNU Compiler CollectionのJavaフロントエンドである
@code{gcj}を使用してコンパイルされるJavaに対するサポートも含まれていま
す.

@c Any package including Java code to be compiled must define the output
@c variable @samp{GCJ} in @file{configure.ac}; the variable @samp{GCJFLAGS}
@c must also be defined somehow (either in @file{configure.ac} or
@c @file{Makefile.am}).  The simplest way to do this is to use the
@c @code{AM_PROG_GCJ} macro.
@c 
Javaコードを含んでいるパッケージのコンパイルには,@file{configure.ac} 
で出力変数@samp{GCJ}を定義する必要があります.変数@samp{GCJFLAGS}も,
(@file{configure.ac}や@file{Makefile.am}で)なんとかして定義する必要が
あります.こうするための最も簡単な方法は,@code{AM_PROG_GCJ}マクロを使
用することです.

@vindex GCJFLAGS

@c By default, programs including Java source files are linked with
@c @code{gcj}.
@c 
デフォルトで,Javaソースファイルを含んでいるプログラムは,@code{gcj}で
リンクされます.

@c As always, the contents of @samp{AM_GCJFLAGS} are passed to every
@c compilation invoking @code{gcj} (in its role as an ahead-of-time
@c compiler -- when invoking it to create @file{.class} files,
@c @samp{AM_JAVACFLAGS} is used instead).  If it is necessary to pass
@c options to @code{gcj} from @file{Makefile.am}, this variable, and not
@c the user variable @samp{GCJFLAGS}, should be used.
@c 
通常どおり,@samp{AM_GCJFLAGS}の内容は,@code{gcj}が呼び出されるコンパ
イルごとに渡されます(コンパイル前でのその役割を果たすもの ---
@file{.class}ファイルを作成するためにそれを呼び出すとき,
@samp{AM_JAVACFLAGS}が代わりに使用されます).@file{Makefile.am}から
@code{gcj}にオプションを渡す必要がある場合,この変数とユーザ変数でない
@samp{GCJFLAGS}を使用すべきでしょう.

@vindex AM_GCJFLAGS

@c @code{gcj} can be used to compile @file{.java}, @file{.class},
@c @file{.zip}, or @file{.jar} files.
@c 
@code{gcj}は,@file{.java},@file{.class},@file{.zip},または
@file{.jar}ファイルをコンパイルするために使用することが可能です.

@c When linking, @code{gcj} requires that the main class be specified
@c using the @samp{--main=} option.  The easiest way to do this is to use
@c the @code{_LDFLAGS} variable for the program.
@c 
リンク時に,@code{gcj}はメインクラスが@samp{--main=}オプションを使用し
て指定されていることを要求します.こうするための最も簡単な方法は,プロ
グラムで@code{_LDFLAGS}変数を使用することです.


@node Support for Other Languages
@comment  node-name,  next,  previous,  up
@c @section Support for Other Languages
@section 他の言語のサポート

@c Automake currently only includes full support for C, C++ (@pxref{C++
@c Support}), Fortran 77 (@pxref{Fortran 77 Support}),
@c Fortran 9x (@pxref{Fortran 9x Support}),
@c and Java (@pxref{Java Support}).  There is only rudimentary support for other
@c languages, support for which will be improved based on user demand.
@c 
Automakeには現在,C,C++(@pxref{C++ Support}),Fortran
77(@pxref{Fortran 77 Support}),Fortran 9x (@pxref{Fortran 9x
Support}),そしてJava(@pxref{Java Support})のみの完全なサポートが含ま
れています.他の言葉に対しては,基本的なサポートとユーザの需要に基づい
て改善されるサポートしかありません.

@c Some limited support for adding your own languages is available via the
@c suffix rule handling; see @ref{Suffixes}.
@c 
独自の言語を加えるため幾分制限されているサポートは,サフィックスルール
の処理によって利用可能になっています.@ref{Suffixes}を参照してください.


@node ANSI
@c @section Automatic de-ANSI-fication
@section 自動的なde-ANSI-fication

@cindex de-ANSI-fication, defined

@c Although the GNU standards allow the use of ANSI C, this can have the
@c effect of limiting portability of a package to some older compilers
@c (notably the SunOS C compiler).
@c 
GNU standardsはANSI Cの使用を許可していますが,これはもっと古いコンパ
イラ(特にSunOS C コンパイラ)へのパッケージの移植性を制限することになる
はずです.

@c Automake allows you to work around this problem on such machines by
@c @dfn{de-ANSI-fying} each source file before the actual compilation takes
@c place.
@c 
実際にコンパイルされる前に@dfn{de-ANSI-fyng}したそれぞれのファイルによっ
て,Automakeではそのようなマシン上でのこの問題を解決することが可能にな
ります.

@vindex AUTOMAKE_OPTIONS
@opindex ansi2knr

@c If the @file{Makefile.am} variable @code{AUTOMAKE_OPTIONS}
@c (@pxref{Options}) contains the option @code{ansi2knr} then code to
@c handle de-ANSI-fication is inserted into the generated
@c @file{Makefile.in}.
@c 
@file{Makefile.am}の変数@code{AUTOMAKE_OPTIONS}(@pxref{Options})がオプ
ション@code{ansi2knr}を含んでいる場合,de-ANSI-ficationを処理するため
のコードが生成された@file{Makefile.in}に挿入されます.

@c This causes each C source file in the directory to be treated as ANSI C@.
@c If an ANSI C compiler is available, it is used.  If no ANSI C compiler
@c is available, the @code{ansi2knr} program is used to convert the source
@c files into K&R C, which is then compiled.
@c 
これによって,ディレクトリ内のそれぞれのCソースファイルをANSI Cとして
扱います.ANSI Cコンパイラが利用可能な場合,それが使用されます.ANSI C 
コンパイラが利用可能でない場合,@code{ansi2knr}プログラムがソースファ
イルをK&R Cに変換するために使用され,そしてコンパイルされます.

@c The @code{ansi2knr} program is simple-minded.  It assumes the source
@c code will be formatted in a particular way; see the @code{ansi2knr} man
@c page for details.
@c 
@code{ansi2knr}プログラムは単純です.それはソースコードが特定の方法で
書式化されると仮定します.詳細は@code{ansi2knr}のmanページを参照してく
ださい.

@c Support for de-ANSI-fication requires the source files @file{ansi2knr.c}
@c and @file{ansi2knr.1} to be in the same package as the ANSI C source;
@c these files are distributed with Automake.  Also, the package
@c @file{configure.ac} must call the macro @code{AM_C_PROTOTYPES}
@c (@pxref{Macros}).
@c 
de-ANSI-ficationに対するサポートでは,ソースファイル@file{ansi2knr.c}
と@file{ansi2knr.1}がANSI Cソースと同じパッケージにある必要があります.
これらのファイルはAutomakeと一緒に配布されます.また,パッケージ
@file{configure.ac}では,@code{AM_C_PROTOTYPES}マクロを呼び出す必要も
あります(@pxref{Macros}).
@cvindex AM_C_PROTOTYPES

@c Automake also handles finding the @code{ansi2knr} support files in some
@c other directory in the current package.  This is done by prepending the
@c relative path to the appropriate directory to the @code{ansi2knr}
@c option.  For instance, suppose the package has ANSI C code in the
@c @file{src} and @file{lib} subdirectories.  The files @file{ansi2knr.c} and
@c @file{ansi2knr.1} appear in @file{lib}.  Then this could appear in
@c @file{src/Makefile.am}:
@c 
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

@c If no directory prefix is given, the files are assumed to be in the
@c current directory.
@c 
ディレクトリの接頭辞が与えられてない場合,ファイルはカレントディレクト
リにあると仮定されます.

@c Note that automatic de-ANSI-fication will not work when the package is
@c being built for a different host architecture.  That is because automake
@c currently has no way to build @code{ansi2knr} for the build machine.
@c 
自動的なde-ANSI-ficationは,パッケージが異なるホストアーキテクチャに対
するビルドでは動作しないことに注意してください.それは,ビルドマシンに
対して@code{ansi2knr}をビルドする方法が,現在のautomakeには無いためで
す.

@c FIXME: this paragraph might be better moved to an `upgrading' section.
@cindex @code{LTLIBOBJS} and @code{ansi2knr}
@cindex @code{LIBOBJS} and @code{ansi2knr}
@cindex @code{ansi2knr} and @code{LTLIBOBJS}
@cindex @code{ansi2knr} and @code{LIBOBJS}
@c Using @code{LIBOBJS} with source de-ANSI-fication used to require
@c hand-crafted code in @file{configure} to append @code{$U} to basenames
@c in @code{LIBOBJS}.  This is no longer true today.  Starting with version
@c 2.54, Autoconf takes care of rewriting @code{LIBOBJS} and
@c @code{LTLIBOBJS}.  (@pxref{AC_LIBOBJ vs LIBOBJS, , @code{AC_LIBOBJ}
@c vs. @code{LIBOBJS}, autoconf, The Autoconf Manual})
@c 
ソースのde-ANSI-ficationで@code{LIBOBJS}を使用すると,@file{configure} 
の@code{LIBOBJS}のbasenameに@code{$U}を手動で追加する必要がありました.
現在ではそうではありません.バージョン2.54から,Autoconfは
@code{LIBOBJS}と@code{LTLIBOBJS}を注意深く書き換えています.
(@pxref{AC_LIBOBJ vs LIBOBJS, , @code{AC_LIBOBJ} vs. @code{LIBOBJS},
autoconf, The Autoconf Manual})

@node Dependencies
@c @section Automatic dependency tracking
@section 自動的な依存性追跡

@c As a developer it is often painful to continually update the
@c @file{Makefile.in} whenever the include-file dependencies change in a
@c project.  Automake supplies a way to automatically track dependency
@c changes.
@c 
プロジェクトで,インクルードファイルの依存性が変化するときはいつでも,
絶えず@file{Makefile.in}を更新することは開発者として辛いことも多いもの
です.Automakeは自動的に依存性の変更を追跡する方法を提供しています.

@cindex Dependency tracking
@cindex Automatic dependency tracking

@c Automake always uses complete dependencies for a compilation, including
@c system headers.  Automake's model is that dependency computation should
@c be a side effect of the build.  To this end, dependencies are computed
@c by running all compilations through a special wrapper program called
@c @code{depcomp}.  @code{depcomp} understands how to coax many different C
@c and C++ compilers into generating dependency information in the format
@c it requires.  @code{automake -a} will install @code{depcomp} into your
@c source tree for you.  If @code{depcomp} can't figure out how to properly
@c invoke your compiler, dependency tracking will simply be disabled for
@c your build.
@c 
Automakeは常に,システムヘッダを含むコンパイルに対する完全な依存性を使
用します.Automakeのモデルは,依存性の評価がビルドの副作用になるという
ものです.つまり依存性は,@code{depcomp}と呼ばれる特別なラッパプログラ
ムを通じてすべてのコンパイルを実行することで求められます.
@code{depcomp}は,多くの異なるCとC++コンパイラで,それが要求する書式で
依存情報の生成させるように上手に扱う方法を理解してます.@code{automake
-a}で,@code{depcomp}をソースツリーにインストールします.
@code{depcomp}がコンパイラの正しい呼び出し方が分からない場合,依存性の
追跡はビルドで利用不可能になるだけです.

@cindex depcomp

@c Experience with earlier versions of Automake @footnote{See
@c @uref{http://sources.redhat.com/automake/dependencies.html} for more
@c information on the history and experiences with automatic dependency
@c tracking in Automake} taught us that it is not reliable to generate
@c dependencies only on the maintainer's system, as configurations vary too
@c much.  So instead Automake implements dependency tracking at build time.
@c 
これまでのバージョンのAutomakeの経験上@footnote{Automakeでの自動的な依
存性の追跡に関する歴史と経験についての情報は,
@uref{http://sources.redhat.com/automake/dependencies.html}を参照して
ください.},configureが非常に多くなるにつれ,管理者のシステムでのみ生
成される依存性が信頼できないことを我々に教えてくれました.そのため,
Automake はビルド時に依存性を追跡することをその代わりに実装しました.

@c Automatic dependency tracking can be suppressed by putting
@c @code{no-dependencies} in the variable @code{AUTOMAKE_OPTIONS}, or
@c passing @code{no-dependencies} as an argument to @code{AM_INIT_AUTOMAKE}
@c (this should be the preferred way).  Or, you can invoke @code{automake}
@c with the @code{-i} option.  Dependency tracking is enabled by default.
@c 
自動的な依存性の追跡で,変数@code{AUTOMAKE_OPTIONS}に
@code{no-dependencies}を書くことや,@code{AM_INIT_AUTOMAKE}への引数と
して@code{no-dependencies}を渡すこと(これは推奨されるべき方法です)が無
くなるはずです.そうしない場合は,@code{automake}を@code{-i}オプション
を用いて呼び出してください.依存性の追跡はデフォルトで利用可能です.

@vindex AUTOMAKE_OPTIONS
@opindex no-dependencies

@c The person building your package also can choose to disable dependency
@c tracking by configuring with @code{--disable-dependency-tracking}.
@c 
パッケージを構築している人々も,@code{--disable-dependency-tracking}を
用いてconfigureすることで,依存性の追跡を利用不可能にすることを選択す
ることが可能です.

@cindex Disabling dependency tracking
@cindex Dependency tracking, disabling


@node EXEEXT
@c @section Support for executable extensions
@section 実行形式の拡張子のサポート

@cindex Executable extension
@cindex Extension, executable
@cindex Windows

@c On some platforms, such as Windows, executables are expected to have an
@c extension such as @samp{.exe}.  On these platforms, some compilers (GCC
@c among them) will automatically generate @file{foo.exe} when asked to
@c generate @file{foo}.
@c 
プラットフォームによっては,Windowsのように実行形式が@samp{.exe}のよう
な拡張子を持つことを期待するものもあります.これらのプラットフォームで
は,(GCCを含む)コンパイラは,@file{foo}を生成するように依頼されるとき,
自動的に@file{foo.exe}を生成します.

@c Automake provides mostly-transparent support for this.  Unfortunately
@c @emph{mostly} doesn't yet mean @emph{fully}.  Until the English
@c dictionary is revised, you will have to assist Automake if your package
@c must support those platforms.
@c 
Automakeは,これに対するほとんどの変換でサポートを提供します.残念なが
ら@emph{ほとんど}とは完全ではないということです.英語の辞書では反対に
なりますが,パッケージをこれらのプラットフォームでサポートされるように
したい場合,Automakeを補助する必要があります.

@c One thing you must be aware of is that, internally, Automake rewrites
@c something like this:
@c 
気付いていると思われることの一つは,Automakeが以下のような内容に内部で
書き直すことです.

@example
bin_PROGRAMS = liver
@end example

@c to this:
@c 
これを以下のようにします.

@example
bin_PROGRAMS = liver$(EXEEXT)
@end example

@c The targets Automake generates are likewise given the @samp{$(EXEEXT)}
@c extension.  @code{EXEEXT}
@c 
Automakeが生成するターゲットは,@samp{$(EXEEXT)}拡張子が与えられたもの
になります.@code{EXEEXT}

@c However, Automake cannot apply this rewriting to @code{configure}
@c substitutions.  This means that if you are conditionally building a
@c program using such a substitution, then your @file{configure.ac} must
@c take care to add @samp{$(EXEEXT)} when constructing the output variable.
@c 
しかし,Automakeがこの書き換えを@code{configure}の置換式に適用すること
は不可能です.そのような置換式を使用しているプログラムを条件付きでビル
ドしている場合,出力変数を作成しているときに@file{configure.ac}に
@samp{$(EXEEXT)}を注意して加えるようにする必要があるということを,これ
は意味します.

@c With Autoconf 2.13 and earlier, you must explicitly use @code{AC_EXEEXT}
@c to get this support.  With Autoconf 2.50, @code{AC_EXEEXT} is run
@c automatically if you configure a compiler (say, through
@c @code{AC_PROG_CC}).
@c 
Autoconf 2.13とそれ以前のものを用いると,このサポートを得るために,明
示的に@code{AC_EXEEXT}を使用する必要があります.Autoconf 2.50を用いる
と,コンパイラをconfigureする際に(すなわち@code{AC_PROG_CC}を通じて),
@code{AC_EXEEXT}が自動的に実行されます.

@c Sometimes maintainers like to write an explicit link rule for their
@c program.  Without executable extension support, this is easy---you
@c simply write a rule whose target is the name of the program.  However,
@c when executable extension support is enabled, you must instead add the
@c @samp{$(EXEEXT)} suffix.
@c 
それらのプログラムに対し,管理者が明示的にリンクルールを書きたいときも
あります.実行形式の拡張子サポートを用いなければ,これは簡単です --- 
ターゲットをプログラム名にしたルールを書くだけです.しかし,実行形式の
拡張子のサポートが利用可能な時は,代わりに@samp{$(EXEEXT)}接尾辞を加え
る必要があります.

@c Unfortunately, due to the change in Autoconf 2.50, this means you must
@c always add this extension.  However, this is a problem for maintainers
@c who know their package will never run on a platform that has
@c executable extensions.  For those maintainers, the @code{no-exeext}
@c option (@pxref{Options}) will disable this feature.  This works in a
@c fairly ugly way; if @code{no-exeext} is seen, then the presence of a
@c rule for a target named @code{foo} in @file{Makefile.am} will override
@c an automake-generated rule for @code{foo$(EXEEXT)}.  Without
@c the @code{no-exeext} option, this use will give a diagnostic.
@c 
残念ながら,Autoconf 2.50の変更のため,常にこの拡張子を加える必要があ
ることを,これは意味しています.しかし,パッケージが実行形式の拡張子を
持つプラットフォームで実行されるはずがないことを知っている管理者にとっ
て,このことは問題になります.これらの管理者に対しては,
@code{no-exeext}オプション(@pxref{Options})でこの機能が利用不可能にな
ります.これは,かなり醜い方法で動作します.@code{no-exeext}が見つかっ
た場合,@file{Makefile.am}の@code{foo}という名前のターゲットに対するルー
ルが存在すると,automekeが生成する@code{foo$(EXEEXT)}に対するルールで
上書きされます.@code{no-exeext}オプションが用いなければ,これでエラー
が生じます.


@node Other objects
@c @chapter Other Derived Objects
@chapter その他の派生されるオブジェクト

@c Automake can handle derived objects which are not C programs.  Sometimes
@c the support for actually building such objects must be explicitly
@c supplied, but Automake will still automatically handle installation and
@c distribution.
@c 
AutomakeはCプログラムではない派生されるオブジェクトを扱うことが可能で
す.このようなオブジェクトを実際にビルドするサポートを明示的に供給する
必要があることもありますが,Automakeは自動的にインストールと配布物を扱
います.

@menu
* Scripts::                     Executable scripts
* Headers::                     Header files
* Data::                        Architecture-independent data files
* Sources::                     Derived sources
@end menu


@node Scripts
@c @section Executable Scripts
@section 実行可能なスクリプト

@cindex _SCRIPTS primary, defined
@cindex SCRIPTS primary, defined
@cindex Primary variable, SCRIPTS

@c It is possible to define and install programs which are scripts.  Such
@c programs are listed using the @samp{SCRIPTS} primary name.  Automake
@c doesn't define any dependencies for scripts; the @file{Makefile.am}
@c should include the appropriate rules.
@c 
スクリプトのプログラムを定義しインストールすることが可能です.そのよう
なプログラムは,@samp{SCRIPTS}プライマリを使用してリストアップします.
Automakeは,スクリプトに対する依存性の定義を全く行ないません.
@file{Makefile.am}に適切なルールを含ませるべきでしょう.
@vindex SCRIPTS

@c Automake does not assume that scripts are derived objects; such objects
@c must be deleted by hand (@pxref{Clean}).
@c 
Automakeはスクリプトがオブジェクトからの派生物であると想定しません.そ
のようなオブジェクトは手動で削除する必要があります(@pxref{Clean}).

@c The @code{automake} program itself is a Perl script that is generated
@c from @file{automake.in}.  Here is how this is handled:
@c 
@code{automake}プログラム自身は,@file{automake.in}から生成されるPerl 
スクリプトです.これを処理する方法は以下のようになります.

@example
bin_SCRIPTS = automake
CLEANFILES = $(bin_SCRIPTS)

do_subst = sed -e 's,[@@]datadir[@@],$(datadir),g' \
            -e 's,[@@]PERL[@@],$(PERL),g' \
            -e 's,[@@]PACKAGE[@@],$(PACKAGE),g' \
            -e 's,[@@]VERSION[@@],$(VERSION),g' \
            @dots{}

automake: automake.in Makefile
        $(do_subst) < $(srcdir)/automake.in > automake
        chmod +x automake
@end example

@c Because---as we have just seen---scripts can be built, they are not
@c distributed by default.  Scripts that should be distributed can be
@c specified using a @code{dist_} prefix as in other primaries.  For
@c instance the following @file{Makefile.am} declares that
@c @file{my_script} should be distributed and installed in
@c @code{$(sbindir)}.
@c 
御覧のように --- スクリプトはビルド可能なので,デフォルトでは配布され
ません.配布されるべきスクリプトは,他のプライマリとして@code{dist_}プ
レフィクスを使用して指定することが可能です.例えば,以下の
@file{Makefile.am}では,@file{my_script}を配布し@code{$(sbindir)}にイ
ンストールするように宣言されています.

@example
dist_sbin_SCRIPTS = my_script
@end example

@cindex SCRIPTS, installation directories
@cindex Installing scripts

@vindex bin_SCRIPTS
@vindex sbin_SCRIPTS
@vindex libexec_SCRIPTS
@vindex pkgdata_SCRIPTS
@vindex noinst_SCRIPTS
@vindex check_SCRIPTS

@c Script objects can be installed in @code{bindir}, @code{sbindir},
@c @code{libexecdir}, or @code{pkgdatadir}.
@c 
スクリプトオブジェクトは@code{bindir},@code{sbindir},
@code{libexecdir},または@code{pkgdatadir}にインストールすることが可能
です.

@c Scripts that need not being installed can be listed in
@c @code{noinst_SCRIPTS}, and among them, those which are needed only by
@c @code{make check} should go in @code{check_SCRIPTS}.
@c 
インストールする必要が無いスクリプトは@code{noinst_SCRIPTS}にリストアッ
プすることが可能で,その中で@code{make check}だけで必要なものは
@code{check_SCRIPTS}に書くべきです.


@node Headers
@c @section Header files
@section ヘッダファイル

@cindex _HEADERS primary, defined
@cindex HEADERS primary, defined
@cindex Primary variable, HEADERS

@vindex noinst_HEADERS
@cindex HEADERS, installation directories
@cindex Installing headers
@vindex include_HEADERS
@vindex oldinclude_HEADERS
@vindex pkginclude_HEADERS


@c Header files that must be installed are specified by the
@c @samp{HEADERS} family of variables.  Headers can be installed in
@c @code{includedir}, @code{oldincludedir}, @code{pkgincludedir} or any
@c other directory you may have defined (@pxref{Uniform}).  For instance
@c 
インストールする必要があるヘッダファイルは,@samp{HEADERS}等の変数で指
定します.ヘッダは@code{includedir},@code{oldincludedir},
@code{pkgincludedir},または,その他の定義済みのディレクトリにインストー
ルすることが可能です(@pxref{Uniform}).例えば以下のようにします.

@example
include_HEADERS = foo.h bar/bar.h
@end example

@noindent
@c will install the two files as @file{$(includedir)/foo.h} and
@c @file{$(includedir)/bar.h}.
@c 
これで,二つのファイルは@file{$(includedir)/foo.h}と
@file{$(includedir)/bar.h}としてインストールされます.

@c The @samp{nobase_} prefix is also supported,
@c 
@samp{nobase_}接頭辞もサポートしています.

@example
nobase_include_HEADERS = foo.h bar/bar.h
@end example

@noindent
@c will install the two files as @file{$(includedir)/foo.h} and
@c @file{$(includedir)/bar/bar.h} (@pxref{Alternative}).
@c 
これで,二つのファイルは@file{$(includedir)/foo.h}と
@file{$(includedir)/bar/bar.h}としてインストールされます
(@pxref{Alternative}).

@vindex noinst_HEADERS
@c Usually, only header files that accompany installed libraries need to
@c be installed.  Headers used by programs or convenience libraries are
@c not installed.  The @code{noinst_HEADERS} variable can be used for
@c such headers.  However when the header actually belongs to one
@c convenient library or program, we recommend listing it in the
@c program's or library's @samp{_SOURCES} variable (@pxref{Program
@c Sources}) instead of in @code{noinst_HEADERS}.  This is clearer for
@c the @file{Makefile.am} reader.  @code{noinst_HEADERS} would be the
@c right variable to use in a directory containing only headers and no
@c associated library or program.
@c 
通常,インストールされているライブラリが必要とするヘッダファイルだけが
インストールされます.プログラムやコンビニエンスライブラリが使用するヘッ
ダはインストールされません.しかし,ヘッダが実際に一つのコンビニエンス
ライブラリやプログラムに属しているとき,我々は,@code{noinst_HEADERS} 
の代わりに,プログラムやライブラリの@samp{_SOURCES}変数でリストアップ
することを推奨します.これで@file{Makefile.am}を読んでいる人がより分か
りやすくなります.@code{noinst_HEADERS}は,ヘッダのみが含まれているディ
レクトリで,関連するライブラリやプログラムがないときに使用してこそ正し
い変数です.

@c All header files must be listed somewhere; in a @samp{_SOURCES}
@c variable or in a @samp{_HEADERS} variable.  Missing ones will not
@c appear in the distribution.
@c 
すべてのヘッダファイルは,どこかにリストアップする必要があります.
@samp{_SOURCES}変数や@samp{_HEADERS}変数にします.行方不明のものは配布
物に含まれません.

@c For header files that are built and must not be distributed, use the
@c @samp{nodist_} prefix as in @code{nodist_include_HEADERS} or
@c @code{nodist_prog_SOURCES}.  If these generated headers are needed
@c during the build, you must also ensure they exist before they are
@c used, see @xref{Sources}.
@c 
ビルドはされますが,配布する必要がないヘッダファイルに対して,
@code{nodist_include_HEADERS}や@code{nodist_prog_SOURCES}のように
@samp{nodist_}接頭辞を使用して下さい.これらの生成されるヘッダがビルド
時に必要な場合,それらが使用される前に存在することを確実にする必要もあ
ります.@xref{Sources}.


@node Data
@c @section Architecture-independent data files
@section アーキテクチャ非依存のデータファイル

@cindex _DATA primary, defined
@cindex DATA primary, defined
@cindex Primary variable, DATA

@c Automake supports the installation of miscellaneous data files using the
@c @samp{DATA} family of variables.
@c 
Automakeは,@samp{DATA}等の変数を使用して様々なデータファイルのインス
トールをサポートします.
@vindex DATA

@vindex data_DATA
@vindex sysconf_DATA
@vindex sharedstate_DATA
@vindex localstate_DATA
@vindex pkgdata_DATA

@c Such data can be installed in the directories @code{datadir},
@c @code{sysconfdir}, @code{sharedstatedir}, @code{localstatedir}, or
@c @code{pkgdatadir}.
@c 
そのようなデータは,ディレクトリ@code{datadir},@code{sysconfdir},
@code{sharedstatedir},@code{localstatedir},または@code{pkgdatadir}に
インストールすること可能です.

@c By default, data files are @emph{not} included in a distribution.  Of
@c course, you can use the @samp{dist_} prefix to change this on a
@c per-variable basis.
@c 
デフォルトで,データファイルは配布物に含まれ@emph{ません}.もちろん,
@samp{dist_}接頭辞を使用することで,変数ごとにこの(デフォルト動作)を変
更することが可能です.

@c Here is how Automake declares its auxiliary data files:
@c 
Automakeでその補助データファイルを宣言する方法は,以下のとおりです.

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


@node Sources
@c @section Built sources
@section ビルドされているソース

@c Because Automake's automatic dependency tracking works as a side-effect
@c of compilation (@pxref{Dependencies}) there is a bootstrap issue: a
@c target should not be compiled before its dependencies are made, but
@c these dependencies are unknown until the target is first compiled.
@c 
Automakeの自動的な依存性追跡は,コンパイルの副作用として働くので
(@pxref{Dependencies}),ブートストラップで問題があります.ターゲットは,
依存性が作成されるまでコンパイルされるべきではありませんが,これらの依
存性は最初にコンパイルされるまで知ることができません.

@c Ordinarily this is not a problem, because dependencies are distributed
@c sources: they preexist and do not need to be built.  Suppose that
@c @file{foo.c} includes @file{foo.h}.  When it first compiles
@c @file{foo.o}, @command{make} only knows that @file{foo.o} depends on
@c @file{foo.c}.  As a side-effect of this compilation @code{depcomp}
@c records the @file{foo.h} dependency so that following invocations of
@c @command{make} will honor it.  In these conditions, it's clear there is
@c no problem: either @file{foo.o} doesn't exist and has to be built
@c (regardless of the dependencies), either accurate dependencies exist and
@c they can be used to decide whether @file{foo.o} should be rebuilt.
@c 
通常,依存性は配布されているソースにあるので,これは問題になりません.
それらは既に存在し,ビルドする必要はありません.@file{foo.c}が
@file{foo.h}をインクルードしていると仮定します.最初に@file{foo.o}にコ
ンパイルするとき,@command{make}は@file{foo.o}が@file{foo.c}に依存する
ことを知っています.このコンパイルの副作用として,それ以降の
@command{make}の呼び出しで尊重されるように,@code{depcomp}が
@file{foo.h}の依存性を記録します.この条件では,問題がないことが明らか
です.つまり,@file{foo.o}が存在せずビルドされていない(依存性には影響
されない),または,正確な依存性が存在し@file{foo.o}をリビルドすべきか
どうかを決定するために使用することが可能であるという,いずれかの状態に
なっています.

@c It's a different story if @file{foo.h} doesn't exist by the first
@c @command{make} run.  For instance there might be a rule to build
@c @file{foo.h}.  This time @file{file.o}'s build will fail because the
@c compiler can't find @file{foo.h}. @command{make} failed to trigger the
@c rule to build @file{foo.h} first by lack of dependency information.
@c 
最初に@command{make}を実行するとき@file{foo.h}が存在しない場合は,別の
話になります.例えば,@file{foo.h}をビルドするルールがあると仮定します.
このとき,コンパイラが@file{foo.h}を見つけることができないので,
@file{file.o}のビルドは失敗します.@command{make}は,依存性の情報が足
りないため,最初に@file{foo.h}をビルドするルールを開始することができま
せん.

@vindex BUILT_SOURCES
@cindex BUILT_SOURCES, defined

@c The @code{BUILT_SOURCES} variable is a workaround for this problem.  A
@c source file listed in @code{BUILT_SOURCES} is made on @code{make all}
@c or @code{make check} (or even @code{make install}) before other
@c targets are processed.  However, such a source file is not
@c @emph{compiled} unless explicitly requested by mentioning it in some
@c other @samp{_SOURCES} variable.
@c 
@code{BUILT_SOURCES}変数でこの問題を回避します.@code{BUILT_SOURCES}で
リストアップされているファイルは,他のターゲットを処理する前に,
@code{make all}や@code{make check}(または,@code{make install}でも)作
成されます.しかし,そのようなソースファイルは,明示的に他の
@samp{_SOURCES}で記述し,要求していない限り@emph{コンパイル}されません.

@c So, to conclude our introductory example, we could use
@c @code{BUILT_SOURCES = foo.h} to ensure @file{foo.h} gets built before
@c any other target (including @file{foo.o}) during @code{make all} or
@c @code{make check}.
@c 
このため,導入する例を決定するため,@code{make all}や@code{make check} 
で(@file{foo.o}を含む)他のターゲットをビルドする前に@file{foo.h}を確実
に入手できるよう,@code{BUILT_SOURCES = foo.h}を使用します.

@c @code{BUILT_SOURCES} is actually a bit of a misnomer, as any file which
@c must be created early in the build process can be listed in this
@c variable.  Moreover, all built sources do not necessarily have to be
@c listed in @code{BUILT_SOURCES}.  For instance a generated @file{.c} file
@c doesn't need to appear in @code{BUILT_SOURCES} (unless it is included by
@c another source), because it's a known dependency of the associated
@c object.
@c 
ビルドプロセスの初期に作成する必要があるファイルは,この変数でリストアッ
プすることが可能なので,@code{BUILT_SOURCES}は実際にはちょっと誤った名
称です.さらに,ビルドされたすべてのソースを,@code{BUILT_SOURCES}にリ
ストアップする必要はありません.例えば,生成される@file{.c}ファイルは,
関連するオブジェクトへの依存性を知っているので,(他のソースからインク
ルードされない限り)@code{BUILT_SOURCES}に書く必要はありません.

@c It might be important to emphasize that @code{BUILT_SOURCES} is
@c honored only by @code{make all}, @code{make check} and @code{make
@c install}.  This means you cannot build a specific target (e.g.,
@c @code{make foo}) in a clean tree if it depends on a built source.
@c However it will succeed if you have run @code{make all} earlier,
@c because accurate dependencies are already available.
@c 
@code{BUILT_SOURCES}は@code{make all},@code{make check},そして
@code{make install}だけを尊重するということを強調しておくのが重要かも
しれません.これは,指定したターゲット(例えば,@code{make foo})が,ビ
ルドソースで依存されていない場合,クリーンなツリーではビルドできないこ
とを意味します.しかし,その前に@code{make all}を実行している場合,依
存性が既に利用可能なように求まっているので,成功します.

@c The next section illustrates and discusses the handling of built sources
@c on a toy example.
@c 
次のセクションでは,ビルドされているソースを処理する簡単な例を説明し,
議論していきます.

@menu
* Built sources example::       Several ways to handle built sources.
@end menu

@node Built sources example
@c @subsection Built sources example
@subsection ビルドされているべきソースの例

@c Suppose that @file{foo.c} includes @file{bindir.h}, which is
@c installation-dependent and not distributed: it needs to be built.  Here
@c @file{bindir.h} defines the preprocessor macro @code{bindir} to the
@c value of the @command{make} variable @code{bindir} (inherited from
@c @file{configure}).
@c 
インストールに依存していて,配布には依存していない@file{bindir.h}をイ
ンクルードしている@file{foo.c}を仮定します.それはビルドで要求されます.
ここで,@file{bindir.h}は,(@file{configure}から継承される)
@command{make}変数@code{bindir}の値をもつプリプロセッサマクロ
@code{bindir}を定義しています,

@c We suggest several implementations below.  It's not meant to be an
@c exhaustive listing of all ways to handle built sources, but it will give
@c you a few ideas if you encounter this issue.
@c 
我々は以下の実装を提案します.ビルドされているソースを処理するすべての
方法のリストを網羅していませんが,この問題に遭遇した場合,ちょっとした
アイデアにはなるでしょう.

@c @unnumberedsubsec First try
@unnumberedsubsec 最初の試み

@c This first implementation will illustrate the bootstrap issue mentioned
@c in the previous section (@pxref{Sources}).
@c 
最初の実装は,前のセクションのブートストラップの問題を説明します
(@pxref{Sources}).

@c Here is a tentative @file{Makefile.am}.
@c 
以下は,試験的な@file{Makefile.am}です.

@example
# This won't work.
bin_PROGRAMS = foo
foo_SOURCES = foo.c
nodist_foo_SOURCES = bindir.h
CLEANFILES = bindir.h
bindir.h: Makefile
        echo '#define bindir "$(bindir)"' >$@@
@end example

@c This setup doesn't work, because Automake doesn't know that @file{foo.c}
@c includes @file{bindir.h}.  Remember, automatic dependency tracking works
@c as a side-effect of compilation, so the dependencies of @file{foo.o} will
@c be known only after @file{foo.o} has been compiled (@pxref{Dependencies}).
@c The symptom is as follows.
@c 
Automakeは,@file{foo.c}が@file{bindir.h}をインクルードすることを知ら
ないので,この設定では動作しません.自動的な依存性の追跡はコンパイルの
副作用として動作するので,@file{foo.o}の依存性は,@file{foo.o}がコンパ
イルされた後になって判明すること(@pxref{Dependencies})を覚えておいて下
さい.症状は以下のようになります.

@example
% make
source='foo.c' object='foo.o' libtool=no \
depfile='.deps/foo.Po' tmpdepfile='.deps/foo.TPo' \
depmode=gcc /bin/sh ./depcomp \
gcc -I. -I. -g -O2 -c `test -f 'foo.c' || echo './'`foo.c
foo.c:2: bindir.h: No such file or directory
make: *** [foo.o] Error 1
@end example

@c In this example @file{bindir.h} is not distributed, not installed, and
@c it is not even being built on-time.  One may wonder what the
@c @code{nodist_foo_SOURCES = bindir.h} line has any use at all.  This
@c line simply states that @file{bindir.h} is a source of @code{foo}, so
@c for instance it should be inspected while generating tags
@c (@pxref{Tags}).  In other words, it does not help our present problem,
@c and the build would fail identically without it.
@c 
この例では,@file{bindir.h}は,配布もインストールもされず,一度もビル
ドされません.@code{nodist_foo_SOURCES = bindir.h}行が全く利用されてい
ないことを不思議に思うかもしれません.この@file{bindir.h}が@code{foo} 
のソースだという単純な行は,例えば,tagを生成している間に検査されるべ
きなので存在します(@pxref{Tags}).言い替えると,ここでの問題には役に立
たず,それが無くても同じようにビルドは失敗します.

@c @unnumberedsubsec Using @code{BUILT_SOURCES}
@unnumberedsubsec @code{BUILT_SOURCES}の使用

@c A solution is to require @file{bindir.h} to be built before anything
@c else.  This is what @code{BUILT_SOURCES} is meant for (@pxref{Sources}).
@c 
解決方法は,他のものをビルドする前に@file{bindir.h}をビルドすることを
要求することです.これこそが,@code{BUILT_SOURCES}が意味することです
(@pxref{Sources}).

@example
bin_PROGRAMS = foo
foo_SOURCES = foo.c
nodist_foo_SOURCES = bindir.h
BUILT_SOURCES = bindir.h
CLEANFILES = bindir.h
bindir.h: Makefile
        echo '#define bindir "$(bindir)"' >$@@
@end example

@c See how @file{bindir.h} get built first:
@c 
@file{bindir.h}が最初にビルドされる様子を見て下さい.

@example
% make
echo '#define bindir "/usr/local/bin"' >bindir.h
make  all-am
make[1]: Entering directory `/home/adl/tmp'
source='foo.c' object='foo.o' libtool=no \
depfile='.deps/foo.Po' tmpdepfile='.deps/foo.TPo' \
depmode=gcc /bin/sh ./depcomp \
gcc -I. -I. -g -O2 -c `test -f 'foo.c' || echo './'`foo.c
gcc  -g -O2   -o foo  foo.o
make[1]: Leaving directory `/home/adl/tmp'
@end example

@c However, as said earlier, @code{BUILT_SOURCES} applies only to the
@c @code{all}, @code{check}, and @code{install} targets.  It still fails
@c if you try to run @code{make foo} explicitly:
@c 
しかし,以前にいったように,@code{BUILT_SOURCES}は@code{all},
@code{check},そして@code{install}ターゲットだけにしか適用されません.
これでは,@code{make foo}を明示的に実行すると失敗します.

@example
% make clean
test -z "bindir.h" || rm -f bindir.h
test -z "foo" || rm -f foo
rm -f *.o
% : > .deps/foo.Po # Suppress previously recorded dependencies
% make foo
source='foo.c' object='foo.o' libtool=no \
depfile='.deps/foo.Po' tmpdepfile='.deps/foo.TPo' \
depmode=gcc /bin/sh ./depcomp \
gcc -I. -I. -g -O2 -c `test -f 'foo.c' || echo './'`foo.c
foo.c:2: bindir.h: No such file or directory
make: *** [foo.o] Error 1
@end example

@c @unnumberedsubsec Recording dependencies manually
@unnumberedsubsec 依存性の手動保存

@c Usually people are happy enough with @code{BUILT_SOURCES} because they
@c never build targets such as @code{make foo} before @code{make all}, as
@c in the previous example.  However if this matters to you, you can
@c avoid @code{BUILT_SOURCES} and record such dependencies explicitly in
@c the @file{Makefile.am}.
@c 
通常,@code{make all}の前に@code{make foo}にようにターゲットをビルドす
ることはないので,前回の例のように@code{BUILT_SOURCES}で十分幸せになれ
ます.しかし,これで問題がある場合,@code{BUILT_SOURCES}を避け,
@file{Makefile.am}に明示的にそのような依存性を記録することが可能です.

@example
bin_PROGRAMS = foo
foo_SOURCES = foo.c
nodist_foo_SOURCES = bindir.h
foo.$(OBJEXT): bindir.h
CLEANFILES = bindir.h
bindir.h: Makefile
        echo '#define bindir "$(bindir)"' >$@@
@end example

@c You don't have to list @emph{all} the dependencies of @code{foo.o}
@c explicitly, only those which might need to be built.  If a dependency
@c already exists, it will not hinder the first compilation and will be
@c recorded by the normal dependency tracking code.  (Note that after this
@c first compilation the dependency tracking code will also have recorded
@c the dependency between @code{foo.o} and @code{bindir.h}; so our explicit
@c dependency is really useful to the first build only.)
@c 
@code{foo.o}の@emph{すべての}依存性をリストアップする必要はなく,ビル
ドに必要なものだけをリストアップします.依存性が既に存在する場合,最初
のコンパイルは邪魔をせず,通常の依存性の追跡コードが記録されます.(こ
の最初のコンパイルの後の依存性の追跡コードも,@code{foo.o}と
@code{bindir.h}の間に記録されることに注意して下さい.そのため,明示的
な依存性は最初のビルドだけで実際に役に立ちます.)

@c Adding explicit dependencies like this can be a bit dangerous if you are
@c not careful enough.  This is due to the way Automake tries not to
@c overwrite your rules (it assumes you know better than it).
@c @code{foo.$(OBJEXT): bindir.h} supersedes any rule Automake may want to
@c output to build @code{foo.$(OBJEXT)}.  It happens to work in this case
@c because Automake doesn't have to output any @code{foo.$(OBJEXT):}
@c target: it relies on a suffix rule instead (i.e., @code{.c.$(OBJEXT):}).
@c Always check the generated @file{Makefile.in} if you do this.
@c 
このような明示的な依存性を追加することで,十分に注意しておかないとちょっ
と危険なことになります.これはAutomakeがルールを上書きしようとしないこ
とに由来します(おそらく,より良いものを知っているでしょう).
@code{foo.$(OBJEXT): bindir.h}で,@code{foo.$(OBJEXT)}をビルドするため
に出力しようとするAutomakeのルールを置き換えます.この状況では,
Automakeは@code{foo.$(OBJEXT):}ターゲットを出力する必要がないので偶然
動作します.それは,代わりにサフィックスルールに関連します(すなわち
@code{.c.$(OBJEXT):}).こうする場合は,常に生成される
@file{Makefile.in}を調査して下さい.

@c @unnumberedsubsec Build @file{bindir.h} from @file{configure}
@unnumberedsubsec @file{configure}から@file{bindir.h}をビルド

@c It's possible to define this preprocessor macro from @file{configure},
@c either in @file{config.h} (@pxref{Defining Directories, , Defining
@c Directories, autoconf, The Autoconf Manual}), or by processing a
@c @file{bindir.h.in} file using @code{AC_CONFIG_FILES}
@c (@pxref{Configuration Actions, ,Configuration Actions, autoconf, The
@c Autoconf Manual}).
@c 
プリプロセッサマクロを@file{configure}から,
@file{config.h}(@pxref{Defining Directories, , Defining Directories,
autoconf, The Autoconf Manual}),または@code{AC_CONFIG_FILES}を使用し
て@file{bindir.h.in}で(@pxref{Configuration Actions, ,Configuration
Actions, autoconf, The Autoconf Manual})定義することも可能です.

@c At this point it should be clear that building @file{bindir.h} from
@c @file{configure} work well for this example.  @file{bindir.h} will exist
@c before you build any target, hence will not cause any dependency issue.
@c 
この時点で,@file{configure}から@file{bindir.h}がビルドされることが明
確になり,この例はうまく動作します.@file{bindir.h}はターゲットをビル
ドする前に存在しているので,依存性の問題は生じません.

@c The Makefile can be shrunk as follows.  We do not even have to mention
@c @file{bindir.h}.
@c 
Makefileは以下のように短くなります.@file{bindir.h}を記述する必要さえ
ありません.

@example
bin_PROGRAMS = foo
foo_SOURCES = foo.c
@end example

@c However, it's not always possible to build sources from
@c @file{configure}, especially when these sources are generated by a tool
@c that needs to be built first...
@c 
しかし,@file{configure}からソースをビルドすることが常に可能だというわ
けではなく,特に,これらのソースが最初にビルドされるツールから生成され
るときがそうなります@enddots{}

@c @unnumberedsubsec Build @file{bindir.c}, not @file{bindir.h}.
@unnumberedsubsec @file{bindir.h}ではなく@file{bindir.c}をビルド

@c Another attractive idea is to define @code{bindir} as a variable or
@c function exported from @file{bindir.o}, and build @file{bindir.c}
@c instead of @file{bindir.h}.
@c 
もう一つの魅力的な考えは,@code{bindir}を@file{bindir.o}からエクスポー
トする変数や関数として定義し,@file{bindir.h}の代わりに@file{bindir.c} 
をビルドする方法です.

@example
noinst_PROGRAMS = foo
foo_SOURCES = foo.c bindir.h
nodist_foo_SOURCES = bindir.c
CLEANFILES = bindir.c
bindir.c: Makefile
        echo 'const char bindir[] = "$(bindir)";' >$@
@end example

@c @file{bindir.h} contains just the variable's declaration and doesn't
@c need to be built, so it won't cause any trouble.  @file{bindir.o} is
@c always dependent on @file{bindir.c}, so @file{bindir.c} will get built
@c first.
@c 
@file{bindir.h}には,宣言された変数だけが含まれていて,ビルドする必要
がないため,問題になることはありません.@file{bindir.o}は,常に
@file{bindir.c}に依存するので,@file{bindir.c}は最初にビルドされます.

@c @unnumberedsubsec Which is best?
@unnumberedsubsec 最善の方法は?

@c There is no panacea, of course.  Each solution has its merits and
@c drawbacks.
@c 
もちろん万能薬はありません.それぞれの解決方法には長所と短所があります.

@c You cannot use @code{BUILT_SOURCES} if the ability to run @code{make
@c foo} on a clean tree is important to you.
@c 
クリーンなツリーで@code{make foo}を実行する能力が重要な場合,
@code{BUILT_SOURCES}を使用することは不可能です.

@c You won't add explicit dependencies if you are leery of overriding
@c an Automake rule by mistake.
@c 
Automakeのルールを間違ってオーバーライドしないように用心している場合,
明示的に依存性を追加しないでしょう.

@c Building files from @file{./configure} is not always possible, neither
@c is converting @file{.h} files into @file{.c} files.
@c 
@file{./configure}からファイルをビルドしたり,@file{.h}ファイルを
@file{.c}ファイルに変換することは,常に可能だというわけではありません.


@node Other GNU Tools
@c @chapter Other GNU Tools
@chapter その他のGNUツール

@c Since Automake is primarily intended to generate @file{Makefile.in}s for
@c use in GNU programs, it tries hard to interoperate with other GNU tools.
@c 
Automakeは,GNUプログラムで使用する@file{Makefile.in}を生成することを
主目的にしているので,他のGNUツールとの相互作用を試みます.

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


@node Emacs Lisp
@section Emacs Lisp

@cindex _LISP primary, defined
@cindex LISP primary, defined
@cindex Primary variable, LISP

@vindex LISP
@vindex lisp_LISP
@vindex noinst_LISP

@c Automake provides some support for Emacs Lisp.  The @samp{LISP} primary
@c is used to hold a list of @file{.el} files.  Possible prefixes for this
@c primary are @samp{lisp_} and @samp{noinst_}.  Note that if
@c @code{lisp_LISP} is defined, then @file{configure.ac} must run
@c @code{AM_PATH_LISPDIR} (@pxref{Macros}).
@c 
Automakeは,Emacs Lispに対するサポートも供給します.@samp{LISP}プライ
マリは@file{.el}ファイルのリストを保持するために使用されます.このプラ
イマリに対して利用可能な接頭辞は@samp{lisp_}と@samp{noinst_}です.
@code{lisp_LISP}が定義されている場合,@file{configure.ac}で
@code{AM_PATH_LISPDIR}を実行する必要があります(@pxref{Macros}).

@c Automake will byte-compile all Emacs Lisp source files using the Emacs
@c found by @code{AM_PATH_LISPDIR}, if any was found.
@c 
AutomakeはすべてのEmacs Lispソースファイルを@code{AM_PATH_LISPDIR}で見
つかった場合はそのEmacsを使用してバイトコンパイルします.

@c Byte-compiled Emacs Lisp files are not portable among all versions of
@c Emacs, so it makes sense to turn this off if you expect sites to have
@c more than one version of Emacs installed.  Furthermore, many packages
@c don't actually benefit from byte-compilation.  Still, we recommend
@c that you byte-compile your Emacs Lisp sources.  It is probably better
@c for sites with strange setups to cope for themselves than to make the
@c installation less nice for everybody else.
@c 
バイトコンパイルされたEmacs Lispファイルは,すべてのEmacsのバージョン
の間で移植性があるわけではないので,一種類以上のEmacsバージョンをイン
ストールしているサイトがあることが予想される場合,これを止めることに意
味があります.さらに,実際にはバイトコンパイルの利点がないパッケージも
多くあります.しかし,我々はEmacs Lispソースをバイトコンパイルすること
を推奨します.恐らく,他の全員がインストールしなくてすむことより,それ
ぞれに対して対処するためにそれぞれ設定した方が良いでしょう.

@c There are two ways to avoid byte-compiling.  Historically, we have
@c recommended the following construct.
@c 
バイトコンパイルを避ける方法は二つあります.歴史的に,我々は以下の内容
を推奨していました.
@example
lisp_LISP = file1.el file2.el
ELCFILES =
@end example
@noindent
@c @code{ELCFILES} is an internal Automake variable that normally lists
@c all @file{.elc} files that must be byte-compiled.  Automake defines
@c @code{ELCFILES} automatically from @code{lisp_LISP}.  Emptying this
@c variable explicitly prevents byte-compilation to occur.
@c 
@code{ELCFILES}はAutomakeの内部変数で,通常はバイトコンパイルする必要
があるすべての@file{.elc}ファイルをリストアップしています.Automakeは
@code{lisp_LISP}から@code{ELCFILES}を自動的に定義します.この変数を明
示的に空にしておくことで,バイトコンパイルを妨げます.

@c Since Automake 1.8, we now recommend using @code{lisp_DATA} instead.  As
@c in
@c 
Automake 1.8からは,我々は代わりに@code{lisp_DATA}を使用することを推奨
しています.以下のようにします.
@example
lisp_DATA = file1.el file2.el
@end example

@c Note that these two constructs are not equivalent.  @code{_LISP} will
@c not install a file if Emacs is not installed, while @code{_DATA} will
@c always install its files.
@c 
これら二つの内容が等価ではないことに注意して下さい.Emacsがインストー
ルされていない場合,@code{_LISP}ではそのファイルはインストールされませ
んが,@code{_DATA}ではそのファイルは常にインストールされます.

@node gettext
@section Gettext

@cindex GNU Gettext support
@cindex Gettext support
@cindex Support for GNU Gettext

@c If @code{AM_GNU_GETTEXT} is seen in @file{configure.ac}, then Automake
@c turns on support for GNU gettext, a message catalog system for
@c internationalization
@c (@pxref{GNU Gettext, , , gettext, GNU gettext utilities}).
@c 
@code{AM_GNU_GETTEXT}が@file{configure.ac}にある場合,Automakeは,国際
化のためのメッセージカタログシステム,GNU gettextに対するサポートを開
始します(@pxref{GNU Gettext, , , gettext, GNU gettext utilities}).

@c The @code{gettext} support in Automake requires the addition of two
@c subdirectories to the package, @file{intl} and @file{po}.  Automake
@c insures that these directories exist and are mentioned in
@c @code{SUBDIRS}.
@c 
Automakeでの@code{gettext}サポートには,パッケージに@file{intl}と
@file{po}の二つのサブディレクトリの追加が必要です.Automakeは,これら
のディレクトリが存在して@code{SUBDIRS}に書かれていることを保証します.

@vindex dist_lisp_LISP
@vindex dist_noinst_LISP
@c Lisp sources are not distributed by default.  You can prefix the
@c @code{LISP} primary with @code{dist_}, as in @code{dist_lisp_LISP} or
@c @code{dist_noinst_LISP}, to indicate that these files should be
@c distributed.
@c 
Lispソースはデフォルトで配布されません.これらのファイルを配布すること
を示すため,@code{dist_lisp_LISP}や@code{dist_noinst_LISP}のように,
@code{LISP}プライマリに@code{dist_}を前置することが可能です.

@node Libtool
@section Libtool

@c Automake provides support for GNU Libtool (@pxref{Top, , Introduction,
@c libtool, The Libtool Manual}) with the @samp{LTLIBRARIES} primary.
@c @xref{A Shared Library}.
@c 
Automakeは,@samp{LTLIBRARIES}プライマリを用いることで,GNU
Libtool(@pxref{Top, , Introduction, libtool, The Libtool Manual})に対
するサポートを提供します.@xref{A Shared Library}.

@node Java
@section Java

@cindex _JAVA primary, defined
@cindex JAVA primary, defined
@cindex Primary variable, JAVA

@c Automake provides some minimal support for Java compilation with the
@c @samp{JAVA} primary.
@c 
Automakeは@samp{JAVA}プライマリを用いることで,Javaコンパイルに対する
最低限のサポートも提供します.

@c Any @file{.java} files listed in a @samp{_JAVA} variable will be
@c compiled with @code{JAVAC} at build time.  By default, @file{.class}
@c files are not included in the distribution.
@c 
@samp{_JAVA}変数でリストアップされているすべての@file{.java}ファイルは,
ビルド時に@code{JAVAC}でコンパイルされます.デフォルトで,
@file{.class} ファイルは配布物に含められません.

@cindex JAVA restrictions
@cindex Restrictions for JAVA

@c Currently Automake enforces the restriction that only one @samp{_JAVA}
@c primary can be used in a given @file{Makefile.am}.  The reason for this
@c restriction is that, in general, it isn't possible to know which
@c @file{.class} files were generated from which @file{.java} files -- so
@c it would be impossible to know which files to install where.  For
@c instance, a @file{.java} file can define multiple classes; the resulting
@c @file{.class} file names cannot be predicted without parsing the
@c @file{.java} file.
@c 
現在のAutomakeには,@samp{_JAVA}プライマリを@file{Makefile.am}で一つだ
けしか使用できないという制限があります.この制限の理由は,どの
@file{.java}ファイルからどの@file{.class}ファイルが生成されるのかが通
常は分からないためです -- そのため,どこにどのファイルをインストールす
るのか分かりません.例えば,@file{.java}ファイルで複数のクラスを定義す
ることが可能です.結果として得られる@file{.class}ファイル名は,
@file{.java}ファイルをパースしない限り特定不可能です.

@c There are a few variables which are used when compiling Java sources:
@c 
Javaソースをコンパイルする時に使用される変数がいくつかあります.

@vtable @code
@item JAVAC
@c The name of the Java compiler.  This defaults to @samp{javac}.
@c 
Javaコンパイラの名前です.デフォルトは,@samp{javac}です.

@item JAVACFLAGS
@c The flags to pass to the compiler.  This is considered to be a user
@c variable (@pxref{User Variables}).
@c 
コンパイラに渡すフラグです.これは,ユーザ変数として考慮されます
(@pxref{User Variables}).

@item AM_JAVACFLAGS
@c More flags to pass to the Java compiler.  This, and not
@c @code{JAVACFLAGS}, should be used when it is necessary to put Java
@c compiler flags into @file{Makefile.am}.
@c 
Javaコンパイラに渡す追加フラグです.@code{JAVACFLAGS}とは異なり,
@file{Makefile.am}にJavaコンパイラフラグを書く必要があるとき,これを使
用すべきではありません.

@item JAVAROOT
@c The value of this variable is passed to the @samp{-d} option to
@c @code{javac}.  It defaults to @samp{$(top_builddir)}.
@c 
この変数の値は,@code{javac}に渡す@samp{-d}オプションです.デフォルト
は,@samp{$(top_builddir)}です.

@item CLASSPATH_ENV
@c This variable is an @code{sh} expression which is used to set the
@c @code{CLASSPATH} environment variable on the @code{javac} command line.
@c (In the future we will probably handle class path setting differently.)
@c 
この変数は,@code{javac}コマンドラインで@code{CLASSPATH}環境変数に設定
するために使用される@code{sh}式です.(将来,クラスパスの設定を異なる方
法で扱うようにする予定です.)
@end vtable


@node Python
@section Python

@cindex _PYTHON primary, defined
@cindex PYTHON primary, defined
@cindex Primary variable, PYTHON


@c Automake provides support for Python compilation with the @samp{PYTHON}
@c primary.
@c 
Automakeは,@samp{PYTHON}プライマリを用いることで,Pythonのコンパイル
に対するサポートを提供します.

@c Any files listed in a @samp{_PYTHON} variable will be byte-compiled with
@c @code{py-compile} at install time.  @code{py-compile} actually creates
@c both standard (@file{.pyc}) and byte-compiled (@file{.pyo}) versions of
@c the source files.  Note that because byte-compilation occurs at install
@c time, any files listed in @samp{noinst_PYTHON} will not be compiled.
@c Python source files are included in the distribution by default.
@c 
@samp{_PYTHON}変数でリストアップされているすべてのファイルは,インストー
ル時に@code{py-compile}でバイトコンパイルされます.@code{py-compile}は,
実際にはソースファイルの標準的なバージョン(@file{.pyc})とバイトコンパ
イルされたバージョン(@file{.pyo})の両方を作成します.バイトコンパイル
はインストール時に行なわれるので,@samp{noinst_PYTHON}にリストアップさ
れているファイルはコンパイルされないことに注意してください.Pythonのソー
スファイルは,デフォルトで配布物に含められます.

@c Automake ships with an Autoconf macro called @code{AM_PATH_PYTHON} which
@c will determine some Python-related directory variables (see below).  If
@c you have called @code{AM_PATH_PYTHON} from @file{configure.ac}, then you
@c may use the following variables to list you Python source files in your
@c variables: @samp{python_PYTHON}, @samp{pkgpython_PYTHON},
@c @samp{pyexecdir_PYTHON}, @samp{pkgpyexecdir_PYTHON}, depending where you
@c want your files installed.
@c 
Automakeは,Pythonに関連するディレクトリ変数(以下を参照してください)を
決定する@code{AM_PATH_PYTHON}と呼ばれるAutoconfとともに出荷されていま
す.@file{configure.ac}で@code{AM_PATH_PYTHON}が呼び出す場合,Pythonソー
スファイルをリストアップするために以下の変数を変数内に使用してもかまい
ません.@samp{python_PYTHON},@samp{pkgpython_PYTHON},
@samp{pyexecdir_PYTHON},@samp{pkgpyexecdir_PYTHON}はファイルをインス
トールしたい場所に依存します.

@c @code{AM_PATH_PYTHON([@var{VERSION}], [@var{ACTION-IF-FOUND}],
@c [@var{ACTION-IF-NOT-FOUND}])} takes three optional arguments.  It will
@c search a Python interpreter on the system.  The first argument, if
@c present, is the minimum version of Python required for this package:
@c @code{AM_PATH_PYTHON} will skip any Python interpreter which is older
@c than @var{VERSION}.  If an interpreter is found and satisfies
@c @var{VERSION}, then @var{ACTION-IF-FOUND} is run.  Otherwise,
@c @var{ACTION-IF-NOT-FOUND} is run.
@c 
@code{AM_PATH_PYTHON([@var{VERSION}], [@var{ACTION-IF-FOUND}],
[@var{ACTION-IF-NOT-FOUND}])}は三つのオプション引数を受け取ります.そ
れはPythonのインタプリタをシステムで探します.最初の引数が存在する場合,
それはパッケージが要求するPythonの最小バージョンです.
@code{AM_PATH_PYTHON}は,@var{VERSION}より古いPythonのインタプリタをス
キップします.インタプリタが見つかり@var{VERSION}を満たしている場合,
@var{ACTION-IF-FOUND}が実行されます.それ以外では
@var{ACTION-IF-NOT-FOUND}が実行されます.

@c If @var{ACTION-IF-NOT-FOUND} is not specified, the default is to abort
@c configure.  This is fine when Python is an absolute requirement for the
@c package.  Therefore if Python >= 2.2 is only @emph{optional} to the
@c package, @code{AM_PATH_PYTHON} could be called as follows.
@c 
@var{ACTION-IF-NOT-FOUND}が指定されていない場合,デフォルトはconfigure 
の中止です.これは,Pythonがパッケージに対する必須条件のときは良いもの
です.このため,Python >= 2.2がパッケージに対して@emph{オプション}の場
合,@code{AM_PATH_PYTHON}を以下のように呼び出すことができます.

@example
  AM_PATH_PYTHON(2.2,, :)
@end example

@c @code{AM_PATH_PYTHON} creates several output variables based on the
@c Python installation found during configuration.
@c 
@code{AM_PATH_PYTHON}は,configureで分かったPythonのインストール状況を
基に,いくつかの出力変数を生成します.

@vtable @code
@item PYTHON
@c The name of the Python executable, or @code{:} if no suitable
@c interpreter could be found.
@c 
Pythonの実行形式の名前,または適切なインタプリタが見つからない場合は
@code{:}です.

@c Assuming @var{ACTION-IF-NOT-FOUND} is used (otherwise @file{./configure}
@c will abort if Python is absent), the value of @code{PYTHON} can be used
@c to setup a conditional in order to disable the relevant part of a build
@c as follows.
@c 
@var{ACTION-IF-NOT-FOUND}が使用されていると仮定すると(それ以外では
Pythonが無い場合,@file{./configure}が中止されます),@code{PYTHON}の値
は,以下のようにビルドに関連する部分を利用不可能にするため,条件設定で
使用することが可能です.

@example
  AM_PATH_PYTHON(,, :)
  AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != :])
@end example


@c If the @var{ACTION-IF-NOT-FOUND}
@c is specified
@c 
@var{ACTION-IF-NOT-FOUND}が使用されている場合,それが実行されます.

@item PYTHON_VERSION
@c The Python version number, in the form @var{major}.@var{minor}
@c (e.g. @samp{1.5}).  This is currently the value of
@c @code{sys.version[:3]}.
@c 
@var{major}.@var{minor}形式(例えば,@samp{1.5})の,Pythonのバージョン
ナンバーです.これは,現在@code{sys.version[:3]}の値です.

@item PYTHON_PREFIX
@c The string @code{$@{prefix@}}.  This term may be used in future work
@c which needs the contents of Python's @code{sys.prefix}, but general
@c consensus is to always use the value from configure.
@c 
文字列@code{$@{prefix@}}です.この単語は,Pythonの@code{sys.prefix}の
内容が必要となる将来の動作で使用されるかもしれませんが,一般的な同意事
項として@code{configure}からの値が常に使用されます.

@item PYTHON_EXEC_PREFIX
@c The string @code{$@{exec_prefix@}}.  This term may be used in future work
@c which needs the contents of Python's @code{sys.exec_prefix}, but general
@c consensus is to always use the value from configure.
@c 
文字列@code{$@{exec_prefix@}}です.この単語は,Pythonの
@code{sys.exec_prefix}の内容が必要となる将来の動作で使用されるかもしれ
ませんが,一般的な同意事項として@code{configure}からの値が常に使用され
ます.

@item PYTHON_PLATFORM
@c The canonical name used by Python to describe the operating system, as
@c given by @code{sys.platform}.  This value is sometimes needed when
@c building Python extensions.
@c 
Pythonがオペレーティングシステムを記述するために使用する標準的な名前で,
@code{sys.platform}で与えられます.この値は,Pythonの拡張をビルドする
時,必要となるときもあります.

@item pythondir
@c The directory name for the @file{site-packages} subdirectory of the
@c standard Python install tree.
@c 
標準的にPythonがインストールされるツリーの,@file{site-packages}サブディ
レクトリのディレクトリの名前です.

@item pkgpythondir
@c This is is the directory under @code{pythondir} which is named after the
@c package.  That is, it is @samp{$(pythondir)/$(PACKAGE)}.  It is provided
@c as a convenience.
@c 
これは,パッケージの後で命名される@code{pythondir}以下のディレクトリで
す.すなわち,それは@samp{$(pythondir)/$(PACKAGE)}です.それは便宜上提
供されます.

@item pyexecdir
@c This is the directory where Python extension modules (shared libraries)
@c should be installed.
@c 
これは,Pythonの拡張モジュール(共有ライブラリ)がインストールされるディ
レクトリです.

@item pkgpyexecdir
@c This is a convenience variable which is defined as
@c @samp{$(pyexecdir)/$(PACKAGE)}.
@c 
これは,@samp{$(pyexecdir)/$(PACKAGE)}として定義されている,便宜上の変
数です.
@end vtable

@c All these directory variables have values that start with either
@c @code{$@{prefix@}} or @code{$@{exec_prefix@}} unexpanded.  This works
@c fine in @file{Makefiles}, but it makes these variables hard to use in
@c @file{configure}.  This is mandated by the GNU coding standards, so
@c that the user can run @code{make prefix=/foo install}.  The Autoconf
@c manual has a section with more details on this topic
@c (@pxref{Installation Directory Variables, , Installation Directory
@c Variables, autoconf, The Autoconf Manual}).
@c 
これらすべてのディレクトリ変数は,展開されていない@code{$@{prefix@}}ま
たは@code{$@{exec_prefix@}}のいずれかで開始される値になります.これは
@file{Makefile}でうまく動作しますが,これらの変数を@file{configure}で
使用することは難しくなります.これはGNUコーディング標準に従っているの
で,ユーザは@code{make prefix=/foo install}を実行することが可能です.
Autoconfのマニュアルには,このトピックの詳細が書かれたセクションがあり
ます(@pxref{Installation Directory Variables, , Installation Directory
Variables, autoconf, The Autoconf Manual}).


@node Documentation
@c @chapter Building documentation
@chapter ドキュメントのビルド

@c Currently Automake provides support for Texinfo and man pages.
@c 
現在Automakeは,Texinfoとman pageに対するサポートを提供します.

@menu
* Texinfo::                     Texinfo
* Man pages::                   Man pages
@end menu


@node Texinfo
@section Texinfo

@cindex _TEXINFOS primary, defined
@cindex TEXINFOS primary, defined
@cindex Primary variable, TEXINFOS
@cindex HTML output using Texinfo
@cindex PDF output using Texinfo
@cindex PS output using Texinfo
@cindex DVI output using Texinfo

@c If the current directory contains Texinfo source, you must declare it
@c with the @samp{TEXINFOS} primary.  Generally Texinfo files are converted
@c into info, and thus the @code{info_TEXINFOS} variable is most commonly used
@c here.  Any Texinfo source file must end in the @file{.texi},
@c @file{.txi}, or @file{.texinfo} extension.  We recommend @file{.texi}
@c for new manuals.
@c 
カレントディレクトリにTexinfoソースを含んでいる場合,@samp{TEXINFOS}プ
ライマリでそれを宣言する必要があります.通常,Texinfoファイルはinfoに
変換されるので,@code{info_TEXINFOS}変数が最も一般的に使用されます.す
べてのTexinfoソースファイルは,@file{.texi},@file{.txi},または
@file{.texinfo}の拡張子で終える必要があります.新しいマニュアルには,
@file{.texi}を推奨します.
@vindex TEXINFOS
@vindex info_TEXINFOS

@c Automake generates rules to build @file{.info}, @file{.dvi}, @file{.ps},
@c @file{.pdf} and @file{.html} files from your Texinfo sources.
@c The @file{.info} files are built by @code{make all} and installed
@c by @code{make install} (unless you use @code{no-installinfo}, see below).
@c The other files can be built on request by @code{make dvi}, @code{make ps},
@c @code{make pdf} and @code{make html}.
@c 
Automakeは,@file{.info},@file{.dvi},@file{.ps},@file{.pdf},そして
@file{.html}ファイルを,Texinfoソースからビルドするルールを生成します.
@file{.info}ファイルは@code{make all}でビルドされ,@code{make install} 
でインストールされます(@code{no-installinfo}を使用していない場合に限り
ます.以下を参照してください).それ以外のファイルは,@code{make dvi},
@code{make ps},@code{make pdf},そして@code{make html}でビルドを要求
することが可能です.

@cindex Texinfo flag, VERSION
@cindex Texinfo flag, UPDATED
@cindex Texinfo flag, EDITION
@cindex Texinfo flag, UPDATED-MONTH

@cindex VERSION Texinfo flag
@cindex UPDATED Texinfo flag
@cindex EDITION Texinfo flag
@cindex UPDATED-MONTH Texinfo flag

@cindex mdate-sh

@c If the @file{.texi} file @code{@@include}s @file{version.texi}, then
@c that file will be automatically generated.  The file @file{version.texi}
@c defines four Texinfo flag you can reference using
@c @code{@@value@{EDITION@}}, @code{@@value@{VERSION@}},
@c @code{@@value@{UPDATED@}}, and @code{@@value@{UPDATED-MONTH@}}.
@c 
@file{.texi}ファイルが@file{version.texi}を@code{@@include}している場
合,そのファイルが自動的に生成されます.ファイル@file{version.texi}は,
四つのTexinfoのフラグを定義し,それは@code{@@value@{EDITION@}},
@code{@@value@{VERSION@}},@code{@@value@{UPDATED@}},そして
@code{@@value@{UPDATED-MONTH@}}を使用することで参照可能です.

@table @code
@item EDITION
@itemx VERSION
@c Both of these flags hold the version number of your program.  They are
@c kept separate for clarity.
@c 
これらのフラグは両方とも,プログラムのバージョンナンバーです.それらは
明確さのために別々にしています.

@item UPDATED
@c This holds the date the primary @file{.texi} file was last modified.
@c 
これは,主要な@file{.texi}ファイルが最後に修正された日付を保持します.

@item UPDATED-MONTH
@c This holds the name of the month in which the primary @file{.texi} file
@c was last modified.
@c 
これは,主要な@file{.texi}ファイルが最後に修正された月名を保持します.
@end table

@c The @file{version.texi} support requires the @code{mdate-sh} program;
@c this program is supplied with Automake and automatically included when
@c @code{automake} is invoked with the @code{--add-missing} option.
@c 
@file{version.texi}サポートには,@code{mdate-sh}プログラムが必要です.
このプログラムはAutomakeと一緒に供給されていて,@code{automake}が
@code{--add-missing}オプションで呼び出されるとき,自動的に含められます.

@c If you have multiple Texinfo files, and you want to use the
@c @file{version.texi} feature, then you have to have a separate version
@c file for each Texinfo file.  Automake will treat any include in a
@c Texinfo file that matches @samp{vers*.texi} just as an automatically
@c generated version file.
@c 
複数のTexinfoファイルがあり,@file{version.texi}の機能を使用したい場合,
それぞれのTexinfoファイルに対し個別のバージョンファイルを持たせる必要
があります.Automakeは@samp{vers*.texi}に一致したTexinfoファイル内に含
まれるものを,単純に自動的に生成されたバージョンファイルとして扱います.

@c Sometimes an info file actually depends on more than one @file{.texi}
@c file.  For instance, in GNU Hello, @file{hello.texi} includes the file
@c @file{gpl.texi}.  You can tell Automake about these dependencies using
@c the @code{@var{texi}_TEXINFOS} variable.  Here is how GNU Hello does it:
@c 
infoファイルが,実際には一つ以上の@file{.texi}ファイルに依存する場合も
あります.例えば,GNU Helloでは,@file{hello.texi}は@file{gpl.texi}ファ
イルを含んでいます.@code{@var{texi}_TEXINFOS}変数を使用することでこれ
らの依存性をAutomakeに伝えることが可能です.GNU Helloで用いた方法は,
以下のようになっています.
@vindex TEXINFOS
@vindex _TEXINFOS

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

@cindex texinfo.tex

@c By default, Automake requires the file @file{texinfo.tex} to appear in
@c the same directory as the Texinfo source (this can be changed using the
@c @code{TEXINFO_TEX} variable, see below).  However, if you used
@c @code{AC_CONFIG_AUX_DIR} in @file{configure.ac} (@pxref{Input, , Finding
@c `configure' Input, autoconf, The Autoconf Manual}), then
@c @file{texinfo.tex} is looked for there.  Automake supplies
@c @file{texinfo.tex} if @samp{--add-missing} is given.
@c 
デフォルトでAutomakeは,ファイル@file{texinfo.tex}がTexinfoソースと同
じディレクトリに存在することを要求します(これは,@code{TEXINFO_TEX}変
数で変更することが可能です.以下を参照して下さい).しかし,
@file{configure.ac}で@code{AC_CONFIG_AUX_DIR}を使用した場合
(@pxref{Input, , Finding `configure' Input, autoconf, The Autoconf
Manual}),@file{texinfo.tex}はそこで探されます.Automakeは,
@samp{--add-missing}が与えられている場合,@file{texinfo.tex}を供給しま
す.

@opindex no-texinfo.tex

@c The option @samp{no-texinfo.tex} can be used to eliminate the
@c requirement for @file{texinfo.tex}.  Use of the variable
@c @code{TEXINFO_TEX} is preferable, however, because that allows the
@c @code{dvi}, @code{ps}, and @code{pdf} targets to still work.
@c 
オプション@samp{no-texinfo.tex}を,@file{texinfo.tex}を要求することを
止めるために使用することが可能です.しかし,変数@code{TEXINFO_TEX}の使
用は望ましく,それは@code{dvi},@code{ps},そして@code{pdf}ターゲット
を動作させることが可能だからです.

@cindex Rule, install-info
@cindex Rule, noinstall-info
@cindex Target, install-info
@cindex Target, noinstall-info
@cindex install-info target
@cindex noinstall-info target

@opindex no-installinfo
@trindex install-info

@c Automake generates an @code{install-info} rule; some people apparently
@c use this.  By default, info pages are installed by @samp{make install}.
@c This can be prevented via the @code{no-installinfo} option.
@c 
Automakeは@code{install-info}ルールを生成します.これを明示的に使用す
る人もいます.デフォルトで,infoページは@samp{make install}でインストー
ルされます.これは@code{no-installinfo}オプションによって止めることが
可能です.

@c The following variables are used by the Texinfo build rules.
@c 
以下の変数はTexinfoのビルドルールで使用されます.

@vtable @code
@item MAKEINFO
@c The name of the program invoked to build @file{.info} files.  This
@c variable is defined by Automake.  If the @code{makeinfo} program is
@c found on the system then it will be used by default; otherwise
@c @code{missing} will be used instead.
@c 
@file{.info}ファイルをビルドするために呼び出されるプログラム名です.こ
の変数はAutomakeが定義します.@code{makeinfo}プログラムがシステムで見
つかった場合,デフォルトで使用されます.それ以外では@code{missing}が代
わりに使用されます.

@item MAKEINFOHTML
@c The command invoked to build @file{.html} files.  Automake
@c defines this to @code{$(MAKEINFO) --html}.
@c 
@file{.html}ファイルをビルドするために呼び出されるコマンドです.
Automakeはこれを@code{$(MAKEINFO) --html}と定義します.

@item MAKEINFOFLAGS
@c User flags passed to each invocation of @code{$(MAKEINFO)} and
@c @code{$(MAKEINFOHTML)}.  This user variable (@pxref{User Variables}) is
@c not expected to be defined in any @file{Makefile}; it can be used by
@c users to pass extra flags to suit their needs.
@c 
@code{$(MAKEINFO)}と@code{$(MAKEINFOHTML)}のそれぞれの呼び出しに渡すユー
ザフラグです.このユーザ変数(@pxref{User Variables})は@file{Makefile} 
で定義していることを期待していません.それはユーザが必要に応じて追加フ
ラグを渡すことで使用することが可能です.

@item AM_MAKEINFOFLAGS
@itemx AM_MAKEINFOHTMLFLAGS
@c Maintainer flags passed to each @code{makeinfo} invocation.  These
@c are maintainer variables that can be overridden in @file{Makefile.am}.
@c @code{$(AM_MAKEINFOFLAGS)} is passed to @code{makeinfo} when building
@c @file{.info} files; and @code{$(AM_MAKEINFOHTMLFLAGS)} is used when
@c building @file{.html} files.
@c 
それぞれの@code{makeinfo}の呼び出しで管理者が渡すフラグです.これらは
@file{Makefile.am}で優先することが可能な管理者用の変数です.
@code{$(AM_MAKEINFOFLAGS)}は@file{.info}ファイルをビルドするとき
@code{makeinfo}に渡されます.そして,@code{$(AM_MAKEINFOHTMLFLAGS)}は
@file{.html}ファイルをビルドするとき@code{makeinfo}に使用されます.

@c For instance the following setting can be used to obtain one single
@c @file{.html} file per manual, without node separators.
@c 
例えば以下の設定で,一つのマニュアルに付き,ノードで分離されていない単
一の@file{.html}ファイルを入手するために使用することが可能です.
@example
AM_MAKEINFOHTMLFLAGS = --no-headers --no-split
@end example

@c By default, @code{$(AM_MAKEINFOHTMLFLAGS)} is set to
@c @code{$(AM_MAKEINFOFLAGS)}.  This means that defining
@c @code{$(AM_MAKEINFOFLAGS)} without defining
@c @code{$(AM_MAKEINFOHTMLFLAGS)} will impact builds of both @file{.info}
@c and @file{.html} files.
@c 
デフォルトで,@code{$(AM_MAKEINFOHTMLFLAGS)}は
@code{$(AM_MAKEINFOFLAGS)}に設定されます.これは,
@code{$(AM_MAKEINFOHTMLFLAGS)}を定義せずに@code{$(AM_MAKEINFOFLAGS)}を
定義すると@file{.info}と@file{.html}の両方のファイルが暗黙にビルドされ
ることを意味します.

@item TEXI2DVI
@c The name of the command that converts a @file{.texi} file into a
@c @file{.dvi} file.  This defaults to @code{texi2dvi}, a script that ships
@c with the Texinfo package.
@c 
@file{.texi}ファイルを@file{.dvi}ファイルに変換するコマンドの名前です.
このデフォルトは@code{texi2dvi}で,Texinfoパッケージとともに配布されて
います.

@item TEXI2PDF
@c The name of the command that translates a @file{.texi} file into a
@c @file{.pdf} file.  This defaults to @code{$(TEXI2DVI) --pdf --batch}.
@c 
@file{.texi}ファイルを@file{.pdf}ファイルに変換するコマンドの名前です.
デフォルトは@code{$(TEXI2DVI) --pdf --batch}です.

@item DVIPS
@c The name of the command that build a @file{.ps} file out of a
@c @file{.dvi} file.  This defaults to @code{dvips}.
@c 
@file{.dvi}ファイルから@file{.ps}ファイルをビルドするコマンドの名前で
す.デフォルトは@code{dvips}です.

@item TEXINFO_TEX

@c If your package has Texinfo files in many directories, you can use the
@c variable @code{TEXINFO_TEX} to tell Automake where to find the canonical
@c @file{texinfo.tex} for your package.  The value of this variable should
@c be the relative path from the current @file{Makefile.am} to
@c @file{texinfo.tex}:
@c 
多くのディレクトリにTexinfoファイルがあるパッケージの場合,Automakeに
パッケージに対して標準的な@file{texinfo.tex}が見つかる場所を伝える変数
@code{TEXINFO_TEX}を使用することが可能です.この変数の値は,現在の
@file{Makefile.am}から@file{texinfo.tex}への相対的なパスにすべきです.

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


@node Man pages
@c @section Man pages
@section manページ

@cindex _MANS primary, defined
@cindex MANS primary, defined
@cindex Primary variable, MANS

@c A package can also include man pages (but see the GNU standards on this
@c matter, @ref{Man Pages, , , standards, The GNU Coding Standards}.)  Man
@c pages are declared using the @samp{MANS} primary.  Generally the
@c @code{man_MANS} variable is used.  Man pages are automatically installed in
@c the correct subdirectory of @code{mandir}, based on the file extension.
@c 
パッケージにmanページを含めることも可能です(しかし,この件に関しては,
@ref{Man Pages, , , standards, The GNU Coding Standards}を参照してくだ
さい).manページは@samp{MANS}プライマリを使用して宣言します.一般に 
@code{man_MANS}変数を使用します.manページは,@code{mandir}の正しいサ
ブディレクトリに,ファイル拡張子に基づいて自動的にインストールされます.
@vindex MANS
@vindex man_MANS

@c File extensions such as @samp{.1c} are handled by looking for the valid
@c part of the extension and using that to determine the correct
@c subdirectory of @code{mandir}.  Valid section names are the digits
@c @samp{0} through @samp{9}, and the letters @samp{l} and @samp{n}.
@c 
@samp{.1c}のようなファイルの拡張子は,有効な拡張子を探すために処理され,
@code{mandir}の正しいサブディレクトリを決定するために使用されます.有
効なセクション名は,10進数の@samp{0}から@samp{9}と,文字の@samp{l}と
@samp{n}です.

@c Sometimes developers prefer to name a man page something like
@c @file{foo.man} in the source, and then rename it to have the correct
@c suffix, e.g. @file{foo.1}, when installing the file.  Automake also
@c supports this mode.  For a valid section named @var{SECTION}, there is a
@c corresponding directory named @samp{man@var{SECTION}dir}, and a
@c corresponding @samp{_MANS} variable.  Files listed in such a variable
@c are installed in the indicated section.  If the file already has a
@c valid suffix, then it is installed as-is; otherwise the file suffix is
@c changed to match the section.
@c 
開発者によっては,ソースファイルで@file{foo.man}のようなファイル名で
manページを命名し,ファイルをインストールするときに,例えば
@file{foo.1}のような正しい接尾子を持つものに名前を変更したい時もありま
す.Automakeはこのモードもサポートします.有効なセクションに命名された
@var{SECTION}に対して,@samp{man@var{SECTION}dir}と命名されている対応
するディレクトリと,対応する@samp{_MANS}変数があります.そのような変数
でリストアップされているファイルは,示されているセクションにインストー
ルされます.ファイルに有効な接尾子が既についている場合,それはそのまま
インストールされます.それ以外の場合,ファイルの接尾子はセクションに一
致するように変更されます.

@c For instance, consider this example:
@c 
例えば,以下のような例を考えます.
@example
man1_MANS = rename.man thesame.1 alsothesame.1c
@end example

@c In this case, @file{rename.man} will be renamed to @file{rename.1} when
@c installed, but the other files will keep their names.
@c 
この場合は,@file{rename.man}はインストールする時に@file{rename.1}に名
前を変更され,他のファイルはその名前のままになります.

@cindex Rule, install-man
@cindex Rule, noinstall-man
@cindex Target, install-man
@cindex Target, noinstall-man
@cindex install-man target
@cindex noinstall-man target

@c Use @samp{make install} per documentation: (texi)code.
@c 
@c By default, man pages are installed by @samp{make install}.  However,
@c since the GNU project does not require man pages, many maintainers do
@c not expend effort to keep the man pages up to date.  In these cases, the
@c @code{no-installman} option will prevent the man pages from being
@c installed by default.  The user can still explicitly install them via
@c @samp{make install-man}.
@c 
デフォルトで,manページは@samp{make install}でインストールされます.し
かし,GNUプロジェクトはmanページを必要としないので,多くの管理者はman
ページを最新にしておきません.この場合,@code{no-installman}オプション
でman ページをデフォルトでインストールしないようにします.ユーザは
@samp{make install-man}によって,明示的にそれらをインストールすること
ができます.
@opindex no-installman
@trindex install-man

@c Here is how the man pages are handled in GNU @code{cpio} (which includes
@c both Texinfo documentation and man pages):
@c 
(Texinfoドキュメントとmanページの両方を含んでいる)GNU@code{cpio}では,
ドキュメントを以下のようにして処理しています.

@example
man_MANS = cpio.1 mt.1
EXTRA_DIST = $(man_MANS)
@end example

@c Man pages are not currently considered to be source, because it is not
@c uncommon for man pages to be automatically generated.  Therefore they
@c are not automatically included in the distribution.  However, this can
@c be changed by use of the @samp{dist_} prefix.
@c 
現在,manページはソースであると考慮されておらず,その理由はmanページが
自動的に生成されることが珍しくないからです.このため,それらは自動的に
配布物に含められません.しかし,これは@samp{dist_}接頭辞を使用すること
で変更可能です.

@c The @samp{nobase_} prefix is meaningless for man pages and is
@c disallowed.
@c 
@samp{nobase_}接頭辞はmanページに対しては意味が無く利用できません.


@node Install
@c @chapter What Gets Installed
@chapter インストールされるもの

@cindex Installation support
@cindex make install support

@c @section Basics of installation
@section 基本的なインストール

@c Naturally, Automake handles the details of actually installing your
@c program once it has been built.  All files named by the various
@c primaries are automatically installed in the appropriate places when the
@c user runs @code{make install}.
@c 
当然,Automakeは,一旦ビルドされたプログラムを実際のインストールの細部
までの処理を行ないます.様々なプライマリで指名されているすべてのファイ
ルは,ユーザが@code{make install}を実行する時に,適切な場所に自動的に
インストールされます.

@c A file named in a primary is installed by copying the built file into
@c the appropriate directory.  The base name of the file is used when
@c installing.
@c 
プライマリで指名されているファイルは,ビルドされたファイルを適切なディ
レクトリにコピーすることでインストールされます.ファイルのベース名はイ
ンストール時に使用されます.

@example
bin_PROGRAMS = hello subdir/goodbye
@end example

@c In this example, both @samp{hello} and @samp{goodbye} will be installed
@c in @code{$(bindir)}.
@c 
この例では,@samp{hello}と@samp{goodbye}の両方が@code{$(bindir)}にイン
ストールされます.

@c Sometimes it is useful to avoid the basename step at install time.  For
@c instance, you might have a number of header files in subdirectories of
@c the source tree which are laid out precisely how you want to install
@c them.  In this situation you can use the @samp{nobase_} prefix to
@c suppress the base name step.  For example:
@c 
インストール時にベース名のステップを避けた方が役に立つこともあるでしょ
う.例えば,ソースツリーのサブディレクトリに,インストール時にインストー
ルしたい方法で正確に配置したいヘッダファイルがいくつかあるかもしれませ
ん.この場合,ベース名のステップを停止するために,@samp{nobase_}接頭辞
を使用することが可能です.例えば以下のようにします.

@example
nobase_include_HEADERS = stdio.h sys/types.h
@end example

@c Will install @file{stdio.h} in @code{$(includedir)} and @file{types.h}
@c in @code{$(includedir)/sys}.
@c 
これで,@file{stdio.h}は@code{$(includedir)}に,そして@file{types.h}は
@code{$(includedir)/sys}にインストールされます.

@c @section The two parts of install
@section インストールの二つの部分

@c Automake generates separate @code{install-data} and @code{install-exec}
@c rules, in case the installer is installing on multiple machines which
@c share directory structure---these targets allow the machine-independent
@c parts to be installed only once.  @code{install-exec} installs
@c platform-dependent files, and @code{install-data} installs
@c platform-independent files.  The @code{install} target depends on both
@c of these targets.  While Automake tries to automatically segregate
@c objects into the correct category, the @file{Makefile.am} author is, in
@c the end, responsible for making sure this is done correctly.
@c 
インストーラーが共有ディレクトリ構造を持っている複数のマシンにインストー
ルする場合,Automakeは@code{install-data}と@code{install-exec}ルールを
分けて生成します --- これらのターゲットで,マシンに依存しない部分を一
度にインストールすることが可能になります.@code{install-exec}はプラッ
トフォームに依存するファイルをインストールし,@code{install-data}はプ
ラットフォームに依存しないファイルをインストールします.@code{install} 
ターゲットはこれらのターゲットの両方に依存します.Automakeは,オブジェ
クトを正しいカテゴリに自動的に区別するよう試みますが,
@file{Makefile.am}の作者は,これが正しく行なわれていることを確かめる責
任があります.
@trindex install-data
@trindex install-exec
@trindex install
@cindex Install, two parts of

@c Variables using the standard directory prefixes @samp{data},
@c @samp{info}, @samp{man}, @samp{include}, @samp{oldinclude},
@c @samp{pkgdata}, or @samp{pkginclude} (e.g. @samp{data_DATA}) are
@c installed by @samp{install-data}.
@c 
@samp{data},@samp{info},@samp{man},@samp{include},
@samp{oldinclude},@samp{pkgdata},または@samp{pkginclude}(例えば 
@samp{data_DATA})といった標準ディレクトリの接頭辞を使用している変数は,
@samp{install-data}でインストールされます.

@c Variables using the standard directory prefixes @samp{bin}, @samp{sbin},
@c @samp{libexec}, @samp{sysconf}, @samp{localstate}, @samp{lib}, or
@c @samp{pkglib} (e.g. @samp{bin_PROGRAMS}) are installed by
@c @samp{install-exec}.
@c 
@samp{bin},@samp{sbin},@samp{libexec},@samp{sysconf},
@samp{localstate},@samp{lib},または@samp{pkglib}(例えば 
@samp{bin_PROGRAMS})といった標準ディレクトリの接頭辞を使用している変数
は, @samp{install-exec}でインストールされます.

@c Any variable using a user-defined directory prefix with @samp{exec} in
@c the name (e.g. @samp{myexecbin_PROGRAMS} is installed by
@c @samp{install-exec}.  All other user-defined prefixes are installed by
@c @samp{install-data}.
@c 
ユーザが定義した名前で,名前に@samp{exec}を含むディレクトリ接頭辞を使
用している変数は(例えば@samp{myexecbin_PROGRAMS}),@samp{install-exec}
でインストールされます.ユーザによって定義されたそれ以外のすべての接頭
辞は,@samp{install-data}でインストールされます.

@c @section Extending installation
@section インストールの拡張

@c It is possible to extend this mechanism by defining an
@c @code{install-exec-local} or @code{install-data-local} rule.  If these
@c rules exist, they will be run at @samp{make install} time.  These
@c rules can do almost anything; care is required.
@c 
@code{install-exec-local}や@code{install-data-local}ルールを定義するこ
とで,このメカニズムを拡張することが可能です.これらのルールが存在する
場合,それらは@samp{make install}時に実行されます.これらのルールでほ
とんどすべてのことが可能になります.注意が必要です.
@trindex install-exec-local
@trindex install-data-local

@c Automake also supports two install hooks, @code{install-exec-hook} and
@c @code{install-data-hook}.  These hooks are run after all other install
@c rules of the appropriate type, exec or data, have completed.  So, for
@c instance, it is possible to perform post-installation modifications
@c using an install hook.
@c 
Automakeは,@code{install-exec-hook}と@code{install-data-hook}の,二つ
のインストールのフックもサポートしています.これらのフックは,適切な形
式,execやdataといった,他のすべてのインストールルールが完了した後で実
行されます.そのため,例えば,インストールのフックを使用して,インストー
ル後の変更を実施することが可能です.
@cindex Install hook

@c @section Staged installs
@section インストールの実行

@vindex DESTDIR
@c Automake generates support for the @samp{DESTDIR} variable in all
@c install rules.  @samp{DESTDIR} is used during the @samp{make install}
@c step to relocate install objects into a staging area.  Each object and
@c path is prefixed with the value of @samp{DESTDIR} before being copied
@c into the install area.  Here is an example of typical DESTDIR usage:
@c 
Automakeは,すべてのインストールルールで,@samp{DESTDIR}変数に対するサ
ポートを生成します.@samp{DESTDIR}は,インストールオブジェクトを実行領
域に再配置する@samp{make install}の段階で使用されます.それぞれのオブ
ジェクトとパスは,インストール領域にコピーされる前に,@samp{DESTDIR}の
値が前置されます.典型的な@samp{DESTDIR}使用法の例は,以下のようになり
ます.

@example
mkdir /tmp/staging &&
make DESTDIR=/tmp/staging install
@end example

@c The @command{mkdir} command avoids a security problem if the attacker
@c creates a symbolic link from @file{/tmp/staging} to a victim area;
@c then @command{make} places install objects in a directory tree built under
@c @file{/tmp/staging}.  If @file{/gnu/bin/foo} and
@c @file{/gnu/share/aclocal/foo.m4} are to be installed, the above command
@c would install @file{/tmp/staging/gnu/bin/foo} and
@c @file{/tmp/staging/gnu/share/aclocal/foo.m4}.
@c 
@command{mkdir}コマンドは,攻撃者が@file{/tmp/staging}が文字通りの領域
にシンボリックリンクを作成する場合のセキュリティ問題を回避します.そし
て,@command{make}はインストールオブジェクトを@file{/tmp/staging}の下
に構築されているディレクトリツリーに配置します.@file{/gnu/bin/foo}と
@file{/gnu/share/aclocal/foo.m4}がインストールされる場合,上のコマンド
では,@file{/tmp/staging/gnu/bin/foo}と
@file{/tmp/staging/gnu/share/aclocal/foo.m4}にインストールされます.

@c This feature is commonly used to build install images and packages.  For
@c more information, see @ref{Makefile Conventions, , , standards, The GNU
@c Coding Standards}.
@c 
この機能は,インストールイメージとパッケージをビルドするために,通常使
用されます.詳細は,@ref{Makefile Conventions, , , standards, The GNU
Coding Standards}を参照してください.

@c Support for @samp{DESTDIR} is implemented by coding it directly into the
@c install rules.  If your @file{Makefile.am} uses a local install rule
@c (e.g., @code{install-exec-local}) or an install hook, then you must
@c write that code to respect @samp{DESTDIR}.
@c 
@samp{DESTDIR}に対するサポートは,インストールルールに直接コーディング
することで実装されています.@file{Makefile.am}でローカルインストール規
則(例えば,@code{install-exec-local})やインストールフックを使用してい
る場合,@samp{DESTDIR}に対応するコードを書く必要があります.

@c @section Rules for the user
@section ユーザのためのルール

@c Automake also generates rules for targets @code{uninstall},
@c @code{installdirs}, and @code{install-strip}.
@c 
Automakeは,ターゲット@code{uninstall},@code{installdirs},そして
@code{install-strip}に対するルールも生成します.
@trindex uninstall
@trindex installdirs
@trindex install-strip

@c Automake supports @code{uninstall-local} and @code{uninstall-hook}.
@c There is no notion of separate uninstalls for ``exec'' and ``data'', as
@c these features would not provide additional functionality.
@c 
Automakeは,@code{uninstall-local}と@code{uninstall-hook}をサポートし
ています.これらの機能は,機能の追加のために提供されているわけでないの
で,``exec''と``data''に対してアンインストールを分ける必要はないでしょ
う.

@c Note that @code{uninstall} is not meant as a replacement for a real
@c packaging tool.
@c 
@code{uninstall}には,実際のパッケージツールを置換する意味が無いことに
注意してください.


@node Clean
@c @chapter What Gets Cleaned
@chapter クリーンされるもの

@cindex make clean support

@c The GNU Makefile Standards specify a number of different clean rules.
@c See @xref{Standard Targets, , Standard Targets for Users, standards,
@c The GNU Coding Standards}.
@c 
GNU Makefile Standardsは多くの異なったクリーンのルールを指定します.
@xref{Standard Targets, , Standard Targets for Users, standards, The
GNU Coding Standards}.

@c Generally the files that can be cleaned are determined automatically by
@c Automake.  Of course, Automake also recognizes some variables that can
@c be defined to specify additional files to clean.  These variables are
@c @code{MOSTLYCLEANFILES}, @code{CLEANFILES}, @code{DISTCLEANFILES}, and
@c @code{MAINTAINERCLEANFILES}.
@c 
一般に,クリーンされるファイルはAutomakeが自動的に決定します.もちろん,
Automakeはクリーンするファイルを追加で指定するために定義することが可能
な変数も認識します.これらの変数は@code{MOSTLYCLEANFILES},
@code{CLEANFILES},@code{DISTCLEANFILES},そして
@code{MAINTAINERCLEANFILES}です.
@vindex MOSTLYCLEANFILES
@vindex CLEANFILES
@vindex DISTCLEANFILES
@vindex MAINTAINERCLEANFILES

@c As the GNU Standards aren't always explicit as to which files should be
@c removed by which rule, we've adopted a heuristic which we believe was
@c first formulated by Fran@,{c}ois Pinard:
@c 
ルールによって削除されるファイルは,GNU Standardsで常に明示されている
というわけではないので,我々は,Fran@,{c}ois Pinardが最初に公式化した
ものを信じて,発見的手法で適用してきました.

@itemize @bullet
@item
@c If @code{make} built it, and it is commonly something that one would
@c want to rebuild (for instance, a @file{.o} file), then
@c @code{mostlyclean} should delete it.
@c 
@code{make}がビルドするもので,通常それをリビルドしたいときがあるもの
(例えば,@file{.o}ファイル)は@code{mostlyclean}でそれを削除します.

@item
@c Otherwise, if @code{make} built it, then @code{clean} should delete it.
@c 
それ以外で,@code{make}でビルドされたものは@code{clean}で削除します.

@item
@c If @code{configure} built it, then @code{distclean} should delete it.
@c 
@code{configure}でビルドされたものは,@code{distclean}で削除します.

@item
@c If the maintainer built it (for instance, a @file{.info} file), then
@c @code{maintainer-clean} should delete it.  However
@c @code{maintainer-clean} should not delete anything that needs to exist
@c in order to run @code{./configure && make}.
@c 
管理者がビルドするもの(例えば@file{.info}ファイル)は,
@code{maintainer-clean}で削除します.しかし,@code{maintainer-clean}で
は,@code{./configure && make}を実行するために必要なものを削除すべきで
はありません.
@end itemize

@c We recommend that you follow this same set of heuristics in your
@c @file{Makefile.am}.
@c 
我々は,皆さんの@file{Makefile.am}で発見的に同じように設定するよう,こ
のことに従って欲しいと思っています.


@node Dist
@c @chapter What Goes in a Distribution
@chapter 配布物に含まれるもの

@c @section Basics of distribution
@section 基本的な配布物

@cindex make dist

@c The @code{dist} rule in the generated @file{Makefile.in} can be used
@c to generate a gzip'd @code{tar} file and other flavors of archive for
@c distribution.  The files is named based on the @samp{PACKAGE} and
@c @samp{VERSION} variables defined by @code{AM_INIT_AUTOMAKE}
@c (@pxref{Macros}); more precisely the gzip'd @code{tar} file is named
@c @samp{@var{package}-@var{version}.tar.gz}.
@c 
@file{Makefile.in}で生成された@code{dist}ルールは,配布物に対してgzip 
された@code{tar}ファイルやそれ以外の特色を持ったものを生成するために使
用することが可能です.ファイルは,@code{AM_INIT_AUTOMAKE}
(@pxref{Macros})で定義される@samp{PACKAGE}と@samp{VERSION}変数に基づい
て命名されます.より正確には,gzipされた@code{tar}ファイルは
@samp{@var{package}-@var{version}.tar.gz}と命名されます.
@cvindex PACKAGE
@cvindex VERSION
@trindex dist
@c You can use the @code{make} variable @samp{GZIP_ENV} to control how gzip
@c is run.  The default setting is @samp{--best}.
@c 
gzipを実行する方法を制御するために,@code{make}の@samp{GZIP_ENV}変数を
使用することが可能です.デフォルト設定は@samp{--best}です.

@c For the most part, the files to distribute are automatically found by
@c Automake: all source files are automatically included in a distribution,
@c as are all @file{Makefile.am}s and @file{Makefile.in}s.  Automake also
@c has a built-in list of commonly used files which are automatically
@c included if they are found in the current directory (either physically,
@c or as the target of a @file{Makefile.am} rule).  This list is printed by
@c @samp{automake --help}.  Also, files which are read by @code{configure}
@c (i.e. the source files corresponding to the files specified in various
@c Autoconf macros such as @code{AC_CONFIG_FILES} and siblings) are
@c automatically distributed.  Files included in @file{Makefile.am}s (using
@c @code{include}) or in @file{configure.ac} (using @code{m4_include}), and
@c helper scripts installed with @samp{automake --add-missing} are also
@c distributed.
@c 
ほとんどの部分で,配布するファイルは自動的にAutomakeが見つけます.ソー
スファイルはすべて自動的に配布物に含まれ,すべての@file{Makefile.am}と
@file{Makefile.in}も同様に扱われます.Automakeには,カレントディレクト
リで(物理的にまたは@file{Makefile.am}ルールのターゲットとして)見つかる
場合に自動的にインクルードされる,一般的に使用されるファイルの組み込み
リストがあります.このリストは@samp{automake --help}で出力されます.
@code{configure}で読み込まれるファイルも(すなわち,
@code{AC_CONFIG_FILES}とその仲間のような様々なAutoconfマクロで指定され
ているファイルに対応しているソースファイル),自動的に配布されます.
(@code{include}を使用して)@file{Makefile.am}や,(@code{m4_include}を使
用して)@file{configure.ac}でインクルードされているファイルと,
@samp{automake --add-missing}でインストールされるヘルパースクリプトも
配布されます.
@cvindex m4_include, distribution

@c Still, sometimes there are files which must be distributed, but which
@c are not covered in the automatic rules.  These files should be listed in
@c the @code{EXTRA_DIST} variable.  You can mention files from
@c subdirectories in @code{EXTRA_DIST}.
@c 
配布する必要がありながら自動的なルールでカバーされていないファイルがあ
ることも,まだあります.これらのファイルは,@code{EXTRA_DIST}変数でリ
ストアップします.@code{EXTRA_DIST}では,サブディレクトリのファイルを
記述することが可能です.

@c You can also mention a directory in @code{EXTRA_DIST}; in this case the
@c entire directory will be recursively copied into the distribution.
@c Please note that this will also copy @emph{everything} in the directory,
@c including CVS/RCS version control files.  We recommend against using
@c this feature.
@c 
@code{EXTRA_DIST}ではディレクトリを記述することも可能です.この場合は,
ディレクトリ全体が再帰的に配布物にコピーされます.これはディレクトリの
@emph{すべてのもの}をコピーし,CVS/RCSのバージョンコントロールファイル
も含まれることに注意してください.我々は,この機能を使用しないことを推
奨します.
@vindex EXTRA_DIST

@c If you define @code{SUBDIRS}, Automake will recursively include the
@c subdirectories in the distribution.  If @code{SUBDIRS} is defined
@c conditionally (@pxref{Conditionals}), Automake will normally include
@c all directories that could possibly appear in @code{SUBDIRS} in the
@c distribution.  If you need to specify the set of directories
@c conditionally, you can set the variable @code{DIST_SUBDIRS} to the
@c exact list of subdirectories to include in the distribution
@c (@pxref{Conditional Subdirectories}).
@c 
@code{SUBDIRS}を定義している場合,Automakeはサブディレクトリを再帰的に
配布物に含めます.@code{SUBDIRS}を条件付きで定義している場合
(@pxref{Conditionals}),Automakeは通常,@code{SUBDIRS}にあるすべてのディ
レクトリをできる限り配布物に含めます.条件付きでディレクトリの組を指定
する必要がある場合,配布物に含めるサブディレクトリの正確なリストを変数
@code{DIST_SUBDIRS}に設定することで可能となります(@pxref{Conditional
Subdirectories}).
@vindex DIST_SUBDIRS


@c @section Fine-grained distribution control
@section きめ細かな配布物の制御

@c Sometimes you need tighter control over what does @emph{not} go into the
@c distribution; for instance you might have source files which are
@c generated and which you do not want to distribute.  In this case
@c Automake gives fine-grained control using the @samp{dist} and
@c @samp{nodist} prefixes.  Any primary or @samp{_SOURCES} variable can be
@c prefixed with @samp{dist_} to add the listed files to the distribution.
@c Similarly, @samp{nodist_} can be used to omit the files from the
@c distribution.
@c 
配布物に含め@emph{ない}ものを細かく制御する必要があるときもあります.
例えば,生成されたソースファイルと配布したくないソースファイルがあると
仮定します.この場合は,Automakeは@samp{dist}と@samp{nodist}接頭辞を使
用したきめ細かな制御を提供します.すべてのプライマリや@samp{_SOURCES}
変数は,リストアップされているファイルを配布物に追加するため,
@samp{dist_}を前置することが可能です.同様に,ファイルを配布物から除去
するために,@samp{nodist_}を使用することが可能です.
@vindex dist_
@vindex nodist_

@c As an example, here is how you would cause some data to be distributed
@c while leaving some source code out of the distribution:
@c 
例えば,配布するデータがあり配布しないソースコードもあるようにする方法
は,以下のようになります.

@example
dist_data_DATA = distribute-this
bin_PROGRAMS = foo
nodist_foo_SOURCES = do-not-distribute.c
@end example

@c @section The dist hook
@section distフック

@trindex dist-hook

@c Occasionally it is useful to be able to change the distribution before
@c it is packaged up.  If the @code{dist-hook} rule exists, it is run
@c after the distribution directory is filled, but before the actual tar
@c (or shar) file is created.  One way to use this is for distributing
@c files in subdirectories for which a new @file{Makefile.am} is overkill:
@c 
パッケージ化する前に,配布物の変更を可能にすことが有効な時もあります.
@code{dist-hook}ルールが存在する場合,配布ディレクトリが満たされた後で,
実際のtar(あるいはshar)ファイルが作成される前に,それが実行されます.
これを利用する方法の一つには,新しい@file{Makefile.am}を作るまでもない
サブディレクトリのファイルを配布するためにあります.

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

@c Another way to to use this is for removing unnecessary files that get
@c recursively included by specifying a directory in EXTRA_DIST:
@c 
これを使用するもう一つの方法は,EXTRA_DISTでディレクトリを指定すること
で,再帰的にインクルードされる不必要なファイルを削除するために存在しま
す.

@example
EXTRA_DIST = doc

dist-hook:
	rm -rf `find $(distdir)/doc -name CVS`
@end example

@vindex distdir
@vindex top_distdir
@c Two variables that come handy when writing @code{dist-hook} rules are
@c @code{$(distdir)} and @code{$(top_distdir)}.
@c 
@code{dist-hook}ルールを書くとき便利な二つの変数は,@code{$(distdir)} 
と@code{$(top_distdir)}です.

@c @code{$(distdir)} points to the directory where the @code{dist} rule
@c will copy files from the current directory before creating the
@c tarball.  If you are at the top-level directory, then @code{distdir =
@c $(PACKAGE)-$(VERSION)}.  When used from subdirectory named
@c @file{foo/}, then @code{distdir = ../$(PACKAGE)-$(VERSION)/foo}.
@c @code{$(distdir)} can be a relative or absolute path, do not assume
@c any form.
@c 
@code{$(distdir)}は,@code{dist}ルールがtarballを作成する前に,ファイ
ルを現在のディレクトリからコピーする場所を示します.最上位のディレクト
リにいる場合,@code{distdir = $(PACKAGE)-$(VERSION)}になります.
@file{foo/}と言う名前のサブディレクトリで使用するときは@code{distdir =
../$(PACKAGE)-$(VERSION)/foo}になります.@code{$(distdir)}は絶対パスや
相対パスが可能で,形式の仮定は行なっていません.


@c @code{$(top_distdir)} always points to the root directory of the
@c distributed tree.  At the top-level it's equal to @code{$(distdir)}.
@c In the @file{foo/} subdirectory
@c @code{top_distdir = ../$(PACKAGE)-$(VERSION)}.
@c @code{$(top_distdir)} too can be a relative or absolute path.
@c 
@code{$(top_distdir)}は,常に配布されるツリーのルートディレクトリを示
します.最上位では,それは@code{$(distdir)}と同じです.@file{foo/}サブ
ディレクトリでは,@code{top_distdir = ../$(PACKAGE)-$(VERSION)}になり
ます.@code{$(top_distdir)}も絶対パスや相対パスが可能です.


@c Note that when packages are nested using @code{AC_CONFIG_SUBDIRS}
@c (@pxref{Subpackages}), then @code{$(distdir)} and
@c @code{$(top_distdir)} are relative to the package where @code{make
@c dist} was run, not to any sub-packages involved.
@c 
パッケージが入れ子状の@code{AC_CONFIG_SUBDIRS}を使用しているとき
(@pxref{Subpackages}),@code{$(distdir)}と@code{$(top_distdir)}が,サ
ブパッケージの呼び出しではなく,@code{make dist}が実行されているパッケー
ジの場所から相対的なものになることに注意して下さい.

@c @section Checking the distribution
@section 配布物の調査

@cindex make distcheck
@cindex make distcleancheck
@vindex distcleancheck_listfiles
@cindex make distuninstallcheck
@vindex distuninstallcheck_listfiles

@c Automake also generates a @code{distcheck} rule which can be of help
@c to ensure that a given distribution will actually work.
@c @code{distcheck} makes a distribution, then tries to do a @code{VPATH}
@c build, run the test suite, and finally make another tarfile to ensure the
@c distribution is self-contained.
@c 
Automakeは,与えられた配布物が実際に動作することの保証に役立つ
@code{distcheck}ルールを生成します.@code{distcheck}は実際に配布物を作
成し,@code{VPATH}のビルドを試み,テストスイートを実行し,そして配布物
自身が含まれることを確認するため,最終的に別のtarファイルを作成します.
@trindex distcheck

@c Building the package involves running @code{./configure}.  If you need
@c to supply additional flags to @code{configure}, define them in the
@c @code{DISTCHECK_CONFIGURE_FLAGS} variable, either in your top-level
@c @file{Makefile.am}, or on the command line when invoking @code{make}.
@c 
パッケージのビルドには,@code{./configure}の実行も含まれます.
@code{configure}に追加フラグを供給する必要がある場合は,最上位の
@file{Makefile.am},または@code{make}の呼出時のコマンドラインで
@code{DISTCHECK_CONFIGURE_FLAGS}変数で定義する必要があります.
@vindex DISTCHECK_CONFIGURE_FLAGS

@c If the @code{distcheck-hook} rule is defined in your top-level
@c @file{Makefile.am}, then it will be invoked by @code{distcheck} after
@c the new distribution has been unpacked, but before the unpacked copy
@c is configured and built.  Your @code{distcheck-hook} can do almost
@c anything, though as always caution is advised.  Generally this hook is
@c used to check for potential distribution errors not caught by the
@c standard mechanism.  Note that @code{distcheck-hook} as well as
@c @code{DISTCHECK_CONFIGURE_FLAGS} are not honored in a subpackage
@c @file{Makefile.am}, but the @code{DISTCHECK_CONFIGURE_FLAGS} are
@c passed down to the @code{configure} script of the subpackage.
@c 
@code{distcheck-hook}ルールがトップレベルの@file{Makefile.am}で定義さ
れている場合,新しい配布物が展開された後,展開されたコピーがconfigure 
されてビルドされる前に,@code{distcheck}で呼び出されます.いつも通りの
注意とアドバイスはありますが,@code{distcheck-hook}でほとんどすべての
ことが可能です.通常このフックは,配布物のエラーが標準的なメカニズムで
発生する可能性を調査するために使用されます.@code{distcheck-hook}は
@code{DISTCHECK_CONFIGURE_FLAGS}と同じように,サブパッケージの
@file{Makefile.am}では利用されませんが,
@code{DISTCHECK_CONFIGURE_FLAGS}はサブパッケージの@code{configure}スク
リプトには渡されることに注意して下さい.

@c Speaking about potential distribution errors, @code{distcheck} will also
@c ensure that the @code{distclean} rule actually removes all built
@c files.  This is done by running @code{make distcleancheck} at the end of
@c the @code{VPATH} build.  By default, @code{distcleancheck} will run
@c @code{distclean} and then make sure the build tree has been emptied by
@c running @code{$(distcleancheck_listfiles)}.  Usually this check will
@c find generated files that you forgot to add to the @code{DISTCLEANFILES}
@c variable (@pxref{Clean}).
@c 
配布物エラーの可能性について述べると,@code{distcheck}では,
@code{distclean}ルールが実際に全てのビルドファイルも確実に削除するとい
うことです.これは,@code{VPATH}のビルドの終りに@code{make
distcleancheck}を実行することでなされます.デフォルトで,
@code{distcleancheck}は@code{distclean}を実行し,
@code{$(distcleancheck_listfiles)}を実行することでビルドツリーが空にな
ることを確かめます.通常この調査は,@code{DISTCLEANFILES}変数
(@pxref{Clean})に追加し忘れた,生成されるファイルを検出します.
@trindex distcleancheck

@c The @code{distcleancheck} behavior should be OK for most packages,
@c otherwise you have the possibility to override the definition of
@c either the @code{distcleancheck} rule, or the
@c @code{$(distcleancheck_listfiles)} variable.  For instance to disable
@c @code{distcleancheck} completely, add the following rule to your
@c top-level @file{Makefile.am}:
@c 
@code{distcleancheck}の動作は,ほとんどのパッケージでOKにすべきで,そ
うでない場合は,@code{distcleancheck}ルールや
@code{$(distcleancheck_listfiles)}変数の定義を優先している可能性があり
ます.@code{distcleancheck}が完全にできないものに対して,最上位の
@file{Makefile.am}に以下のルールを追加してください.
@vindex distcleancheck_listfiles

@example
distcleancheck:
        @@:
@end example

@c If you want @code{distcleancheck} to ignore built files which have not
@c been cleaned because they are also part of the distribution, add the
@c following definition instead:
@c 
配布物の一部にもなるためクリーンしたくないビルドされたファイルを
@code{distcleancheck}で無視したい場合,代わりに以下の定義を追加してく
ださい.

@example
distcleancheck_listfiles = \
  find -type f -exec sh -c 'test -f $(srcdir)/@{@} || echo @{@}' ';'
@end example

@c The above definition is not the default because it's usually an error if
@c your Makefiles cause some distributed files to be rebuilt when the user
@c build the package.  (Think about the user missing the tool required to
@c build the file; or if the required tool is built by your package,
@c consider the cross-compilation case where it can't be run.)  There is
@c a FAQ entry about this (@pxref{distcleancheck}), make sure you read it
@c before playing with @code{distcleancheck_listfiles}.
@c 
ユーザがパッケージをビルドするとき,Makefileが配布されたファイルをリビ
ルドするものがある場合,それは通常エラーとなるので,上記の定義はデフォ
ルトではありません.(ファイルをビルドするために必要なユーザに足りない
ツールを考えてみてください.または,要求されたツールがパッケージでビル
ドされる場合,実行不可能なクロスコンパイルの状況を考慮してください.) 
これに関するFAQがあり(@pxref{distcleancheck}),
@code{distcleancheck_listfiles}を実行する前にそれをよく読んで下さい.

@c @code{distcheck} also checks that the @code{uninstall} rule works
@c properly, both for ordinary and @samp{DESTDIR} builds.  It does this
@c by invoking @code{make uninstall}, and then it checks the install tree
@c to see if any files are left over.  This check will make sure that you
@c correctly coded your @code{uninstall}-related rules.
@c 
@code{distcheck}は,@code{uninstall}ルールが,通常の場合と
@samp{DESTDIR}でのビルドの両方で適切に動作するかどうかも調査します.そ
れは@code{make uninstall}の呼び出しで行ない,ファイルが残っていないか
どうかをインストールツリーを見て調査します.この調査で,
@code{uninstall}に関連するルールを正しくコーディングしていることを確認
します.

@c By default, the checking is done by the @code{distuninstallcheck} rule,
@c and the list of files in the install tree is generated by
@c @code{$(distuninstallcheck_listfiles}) (this is a variable whose value is
@c a shell command to run that prints the list of files to stdout).
@c 
デフォルトで,その調査は@code{distuninstallcheck}ルールで行なわれ,イ
ンストールツリーのファイルリストは,
@code{$(distuninstallcheck_listfiles)}で生成されます(これは,ファイル
リストを標準出力に出力するために実行するシェルコマンドを値に持つ変数で
す).

@c Either of these can be overridden to modify the behavior of
@c @code{distcheck}.  For instance, to disable this check completely, you
@c would write:
@c 
これらのいずれかで,@code{distcheck}の動作を変更するために優先させるこ
とが可能です.例えば,この調査を完全に無効にするため,以下のように書く
でしょう.

@example
distuninstallcheck:
        @@:
@end example

@c @section The types of distributions
@section 配布物の形式

@c Automake generates rules to provide archives of the project for
@c distributions in various formats.  Their targets are:
@c 
Automakeは,様々なフォーマットでプロジェクトを配布するアーカイブを提供
するためのルールを生成します.ターゲットは以下のとおりです.

@table @asis
@item @code{dist-bzip2}
@c Generate a bzip2 tar archive of the distribution.  bzip2 archives are
@c frequently smaller than gzipped archives.
@c 
配布物のbzip2されたtarアーカイブを生成します.bzip2アーカイブは,gzip 
されたアーカイブより小さくなることが多くなっています.
@trindex dist-bzip2

@item @code{dist-gzip}
@c Generate a gzip tar archive of the distribution.
@c 
gzipされたtarアーカイブを生成します.
@trindex dist-gzip

@item @code{dist-shar}
@c Generate a shar archive of the distribution.
@c 
配布物のsharアーカイブを生成します.
@trindex dist-shar

@item @code{dist-zip}
@c Generate a zip archive of the distribution.
@c 
配布物のzipアーカイブを生成します.
@trindex dist-zip

@item @code{dist-tarZ}
@c Generate a compressed tar archive of
@c the distribution.
@c 
配布物の圧縮されたtarアーカイブを生成します.
@trindex dist-tarZ
@end table

@c The rule @code{dist} (and its historical synonym @code{dist-all}) will
@c create archives in all the enabled formats, @ref{Options}.  By
@c default, only the @code{dist-gzip} target is hooked to @code{dist}.
@c 
ルール@code{dist}(とその歴史的な同義語の@code{dist-all})は,利用可能な
すべてのフォーマットでアーカイブを作成します.@ref{Options}を参照して
下さい.デフォルトでは,@code{dist-gzip}ターゲットだけが@code{dist}で
フックされます.


@node Tests
@c @chapter Support for test suites
@chapter テストスイートのサポート

@cindex Test suites
@cindex make check

@c Automake supports two forms of test suites.
@c 
Automakeは二つの形式のテストスイートをサポートします.

@c @section Simple Tests
@section 単純なテスト

@c If the variable @code{TESTS} is defined, its value is taken to be a list
@c of programs to run in order to do the testing.  The programs can either
@c be derived objects or source objects; the generated rule will look both
@c in @code{srcdir} and @file{.}.  Programs needing data files should look
@c for them in @code{srcdir} (which is both an environment variable and a
@c make variable) so they work when building in a separate directory
@c (@pxref{Build Directories, , Build Directories , autoconf, The Autoconf
@c Manual}), and in particular for the @code{distcheck} rule
@c (@pxref{Dist}).
@c 
変数@code{TESTS}が定義されている場合,その値はテストを行なうために実行
するプログラムのリストになります.プログラムは,派生するオブジェクトあ
るいはソースオブジェクトです.生成されるルールは@code{srcdir}と
@file{.}の両方で探します.データファイルを必要としているプログラムは,
(環境変数とmake変数の両方の)@code{srcdir}でそれらを探すので,それらは,
別々のディレクトリでビルドするとき(@pxref{Build Directories, , Build
Directories , autoconf, The Autoconf Manual}),特に@code{distcheck}ルー
ルに対して動作します(@pxref{Dist}).

@cindex Exit status 77, special interpretation

@c The number of failures will be printed at the end of the run.  If a
@c given test program exits with a status of 77, then its result is ignored
@c in the final count.  This feature allows non-portable tests to be
@c ignored in environments where they don't make sense.
@c 
失敗の数は実行後に出力されます.所定のテストプログラムが77のステータス
で終了する場合,その結果は最終的なカウントで無視されます.この機能で,
非移植性のテストが意味をなさない環境で無視することができます.

@c The variable @code{TESTS_ENVIRONMENT} can be used to set environment
@c variables for the test run; the environment variable @code{srcdir} is
@c set in the rule.  If all your test programs are scripts, you can also
@c set @code{TESTS_ENVIRONMENT} to an invocation of the shell (e.g.
@c @samp{$(SHELL) -x}); this can be useful for debugging the tests.
@c 
変数@code{TESTS_ENVIRONMENT}は,テストの実行に対して環境変数を設定する
ために使用することが可能です.環境変数@code{srcdir}は,ルール内に設定
されます.すべてのテストプログラムがスクリプトの場合,
@code{TESTS_ENVIRONMENT}をシェルの呼び出しに設定することが可能です(例
えば@samp{$(SHELL) -x}).これはテストをデバッグするときに役立つはずで
す.
@vindex TESTS
@vindex TESTS_ENVIRONMENT

@cindex Tests, expected failure
@cindex Expected test failure

@c You may define the variable @code{XFAIL_TESTS} to a list of tests
@c (usually a subset of @code{TESTS}) that are expected to fail.  This will
@c reverse the result of those tests.
@c 
変数@code{XFAIL_TESTS}を,失敗を期待するテストのリスト(通常は
@code{TESTS}のサブセット)に定義してもかまいません.これは,それらのテ
ストの結果を反転します.
@vindex XFAIL_TESTS

@c Automake ensures that each program listed in @code{TESTS} is built
@c before any tests are run; you can list both source and derived programs
@c in @code{TESTS}.  For instance, you might want to run a C program as a
@c test.  To do this you would list its name in @code{TESTS} and also in
@c @code{check_PROGRAMS}, and then specify it as you would any other
@c program.
@c 
Automakeは,@code{TESTS}でリストアップされているそれぞれのプログラムが,
テストを実行する前にビルドされることを確実にします.ソースと派生するプ
ログラムを@code{TESTS}にリストアップすることが可能です.例えば,テスト
としてCプログラムを実行したいかもしれません.こうするためには,その名
前を@code{TESTS}と@code{check_PROGRAMS}にもリストアップし,それを他の
プログラムとして指定します.


@c @section DejaGnu Tests
@section DejaGnuのテスト

@c If @uref{ftp://ftp.gnu.org/gnu/dejagnu/, @samp{dejagnu}} appears in
@c @code{AUTOMAKE_OPTIONS}, then a @code{dejagnu}-based test suite is
@c assumed.  The variable @code{DEJATOOL} is a list of names which are
@c passed, one at a time, as the @code{--tool} argument to @code{runtest}
@c invocations; it defaults to the name of the package.
@c 
@uref{ftp://ftp.gnu.org/gnu/dejagnu/, @samp{dejagnu}}が
@code{AUTOMAKE_OPTIONS}にある場合,@code{dejagnu}ベースのテストスイー
トが想定されます.変数@code{DEJATOOL}は,@code{runtest}の呼び出しに
@code{--tool}引数として,一度に渡される名前のリストです.それはパッケー
ジの名前をデフォルトとします.

@c The variable @code{RUNTESTDEFAULTFLAGS} holds the @code{--tool} and
@c @code{--srcdir} flags that are passed to dejagnu by default; this can be
@c overridden if necessary.
@c 
変数@code{RUNTESTDEFAULTFLAGS}は,デフォルトでdejagnuに渡される
@code{--tool}と@code{--srcdir}フラグを保持します.必要な場合は,これで
優先することが可能です.
@vindex RUNTESTDEFAULTFLAGS

@c The variables @code{EXPECT} and @code{RUNTEST} can
@c also be overridden to provide project-specific values.  For instance,
@c you will need to do this if you are testing a compiler toolchain,
@c because the default values do not take into account host and target
@c names.
@c 
変数@code{EXPECT}と@code{RUNTEST}で,プロジェクト特有の値を提供するた
めに優先することが可能です.例えば,コンパイラツールチェインをテストす
る場合,デフォルト値はホストとターゲットの名前を考慮しないので,こうす
る必要があります.
@opindex dejagnu
@vindex DEJATOOL
@vindex EXPECT
@vindex RUNTEST

@c The contents of the variable @code{RUNTESTFLAGS} are passed to the
@c @code{runtest} invocation.  This is considered a ``user variable''
@c (@pxref{User Variables}).  If you need to set @code{runtest} flags in
@c @file{Makefile.am}, you can use @code{AM_RUNTESTFLAGS} instead.
@c 
変数@code{RUNTESTFLAGS}の内容は,@code{runtest}の呼び出しに渡されます.
これは,``ユーザ変数''(@pxref{User Variables})として扱われます.
@file{Makefile.am}に@code{runtest}フラグを設定する必要がある場合,代わ
りに@code{AM_RUNTESTFLAGS}を使用することが可能です.
@vindex RUNTESTFLAGS
@vindex AM_RUNTESTFLAGS

@cindex @file{site.exp}
@c Automake will generate rules to create a local @file{site.exp} file,
@c defining various variables detected by @code{./configure}.  This file
@c is automatically read by DejaGnu.  It is OK for the user of a package
@c to edit this file in order to tune the test suite.  However this is
@c not the place where the test suite author should define new variables:
@c this should be done elsewhere in the real test suite code.
@c Especially, @file{site.exp} should not be distributed.
@c 
Automakeは,@code{./configure}で検出した様々な変数を定義するローカルな
@file{site.exp}ファイルを生成するためのルールを生成します.このファイ
ルは,自動的にDejaGnuで読み込まれます.パッケージユーザがテストスイー
トを調整するためにこのファイルを編集することは問題ありません.しかし,
テストスイートの著者が新しい変数を定義する場所ではありません.これは,
実際のテストスイートのコードのどこかでなされるべきです.特に,
@file{site.exp}を配布すべきではありません.

@c For more information regarding DejaGnu test suites, see @xref{Top, , ,
@c dejagnu, The DejaGnu Manual}.
@c 
DejaGnuのテストスイートに関する詳細は,@xref{Top, , , dejagnu, The
DejaGnu Manual}.

@c In either case, the testing is done via @samp{make check}.
@c 
どちらの状況でも,テストは@samp{make check}で実行されます.

@c @section Install Tests
@section インストールテスト

@c The @code{installcheck} target is available to the user as a way to
@c run any tests after the package has been installed.  You can add tests
@c to this by writing an @code{installcheck-local} rule.
@c 
@code{installcheck}ターゲットは,パッケージがインストールされた後でテ
ストを実行する方法をユーザが利用可能にします.
@code{installcheck-local}ルールを書くことで,これをテストに追加するこ
とが可能です.


@node Rebuilding
@c @chapter Rebuilding Makefiles
@chapter Makefileのリビルド
@cindex rebuild rules

@c Automake generates rules to automatically rebuild @file{Makefile}s,
@c @file{configure}, and other derived files like @file{Makefile.in}.
@c 
Automakeは,@file{Makefile},@file{configure},そして
@file{Makefile.in}のようなその他の派生するファイルを,自動的にリビルド
するルールを生成します.

@cvindex AM_MAINTAINER_MODE
@c If you are using @code{AM_MAINTAINER_MODE} in @file{configure.ac}, then
@c these automatic rebuilding rules are only enabled in maintainer mode.
@c 
@file{configure.ac}で@code{AM_MAINTAINER_MODE}を使用している場合,これ
らの自動的なリビルドのルールは,管理者モードでのみ利用可能になります.

@vindex ACLOCAL_AMFLAGS
@c Sometimes you need to run @code{aclocal} with an argument like @code{-I}
@c to tell it where to find @file{.m4} files.  Since sometimes @code{make}
@c will automatically run @code{aclocal}, you need a way to specify these
@c arguments.  You can do this by defining @code{ACLOCAL_AMFLAGS}; this
@c holds arguments which are passed verbatim to @code{aclocal}.  This variable
@c is only useful in the top-level @file{Makefile.am}.
@c 
@file{.m4}ファイルを探す場所を伝えるために,@code{-I}のような引数を用
いて@code{aclocal}実行する必要があることもあります.@code{make}が自動
的に@code{aclocal}を実行するときもあるので,これらの引数を指定する方法
が必要になります.@code{ACLOCAL_AMFLAGS}を定義することで,こうすること
が可能になります.これは,@code{aclocal}に渡す引数をそのまま保持してい
ます.この変数は,最上位の@file{Makefile.am}でのみ役に立ちます.

@vindex CONFIG_STATUS_DEPENDENCIES
@vindex CONFIGURE_DEPENDENCIES
@cindex @file{version.sh}, example
@cindex @file{version.m4}, example

@c Sometimes it is convenient to supplement the rebuild rules for
@c @file{configure} or @file{config.status} with additional dependencies.
@c The variables @code{CONFIGURE_DEPENDENCIES} and
@c @code{CONFIG_STATUS_DEPENDENCIES} can be used to list these extra
@c dependencies.  These variable should be defined in all
@c @file{Makefile}s of the tree (because these two rebuild rules are
@c output in all them), so it is safer and easier to @code{AC_SUBST} them
@c from @file{configure.ac}.  For instance the following statement will
@c cause @file{configure} to be rerun each time @file{version.sh} is
@c changed.
@c 
追加の依存性を用いて@file{configure}や@file{config.status}をリビルドす
るルールを補足すると便利なときもあります.変数
@code{CONFIGURE_DEPENDENCIES}と@code{CONFIG_STATUS_DEPENDENCIES}をこれ
らの追加の依存性をリストアップするために使用することが可能です.これら
の変数はツリー内のすべての@file{Makefile}で定義されるべきなので(これら
二つのリビルドルールはすべてのものに出力されるため),
@file{configure.ac}で@code{AC_SUBST}するのが安全で簡単です.例えば以下
の文で,@file{version.sh}が変更されるたび@file{configure}が再実行され
ます.
@example
AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ['$(top_srcdir)/version.sh'])
@end example
@noindent
@c Note the @code{$(top_srcdir)/} in the filename.  Since this variable
@c is to be used in all @file{Makefile}s, its value must be sensible at
@c any level in the build hierarchy.
@c 
ファイル名に@code{$(top_srcdir)/}があることに注意して下さい.この変数
はすべての@file{Makefile}で使用されるので,その値はビルドの階層レベル
を知っておく必要があります.

@c Beware not to mistake @code{CONFIGURE_DEPENDENCIES} for
@c @code{CONFIG_STATUS_DEPENDENCIES}.
@c 
@code{CONFIG_STATUS_DEPENDENCIES}に対する@code{CONFIGURE_DEPENDENCIES} 
を誤解しないように注意して下さい.

@c @code{CONFIGURE_DEPENDENCIES} adds dependencies to the
@c @file{configure} rule, whose effect is to run @code{autoconf}.  This
@c variable should be seldom used, because @code{automake} already tracks
@c @code{m4_include}d files.  However it can be useful when playing
@c tricky games with @code{m4_esyscmd} or similar non-recommendable
@c macros with side effects.
@c 
@code{CONFIGURE_DEPENDENCIES}は@file{configure}ルールに依存性を追加し,
それは@code{autoconf}を実行することになります.@code{automake}は既に
@code{m4_include}されるファイルを追跡しているので,この変数は,滅多に
使用すべきではありません.しかし,@code{m4_esyscmd}やそれに似た副作用
のある推奨されていないマクロを用いたトリッキーなゲームを楽しんでいると
き役に立つはずです.

@c @code{CONFIG_STATUS_DEPENDENCIES} adds dependencies to the
@c @file{config.status} rule, whose effect is to run @file{configure}.
@c This variable should therefore carry any non-standard source that may
@c be read as a side effect of running configure, like @file{version.sh}
@c in the example above.
@c 
@code{CONFIG_STATUS_DEPENDENCIES}は@file{config.status}ルールに依存性
を追加し,それは@file{configure}を実行することになります.このため,こ
の変数として,configureの実行に副作用として読み込まれる可能性がないよ
うに,標準的ではないソースを持ち込むべきで,例えば上記の例の
@file{version.sh}などです.

@c Speaking of @file{version.sh} scripts, we recommend against them
@c today.  They are mainly used when the version of a package is updated
@c automatically by a script (e.g., in daily builds).  Here is what some
@c old-style @file{configure.ac}s may look like:
@c 
@file{version.sh}スクリプトについて言わせてもらうと,我々は今日,それ
を推奨していません.それらは主に,パッケージのバージョンをスクリプトで
自動的に更新するとき使用されていました(例えば,毎日のビルド).古い形式
の@file{configure.ac}は以下のようになっているものもありました.
@example
AC_INIT
. $srcdir/version.sh
AM_INIT_AUTOMAKE([name], $VERSION_NUMBER)
@dots{}
@end example
@noindent
@c Here, @file{version.sh} is a shell fragment that sets
@c @code{VERSION_NUMBER}.  The problem with this example is that
@c @code{automake} cannot track dependencies (listing @file{version.sh}
@c in @code{CONFIG_STATUS_DEPENDENCIES}, and distributing this file is up
@c to the user), and that it uses the obsolete form of @code{AC_INIT} and
@c @code{AM_INIT_AUTOMAKE}.  Upgrading to the new syntax is not
@c straightforward, because shell variables are not allowed in
@c @code{AC_INIT}'s arguments.  We recommend that @file{version.sh} be
@c replaced by an M4 file that is included by @file{configure.ac}:
@c 
ここで,@file{version.sh}はシェルの断片で,@code{VERSION_NUMBER}を設定
します.この例の問題は,@code{automake}が依存性を追跡できないことと
(@file{version.sh}を@code{CONFIG_STATUS_DEPENDENCIES}にリストアップし,
このファイルをユーザに配布する),古い形式の@code{AC_INIT}と
@code{AM_INIT_AUTOMAKE}を使用していることです.新しい構文に更新するの
は,@code{AC_INIT}の引数でシェル変数が利用できないので,素直な方法では
ありません.我々は@file{version.sh}を@file{configure.ac}でインクルード
されるM4ファイルで置換することを推奨します.
@example
m4_include([version.m4])
AC_INIT([name], VERSION_NUMBER)
AM_INIT_AUTOMAKE
@dots{}
@end example
@noindent
@c Here @file{version.m4} could contain something like
@c @code{m4_define([VERSION_NUMBER], [1.2])}.  The advantage of this
@c second form is that @code{automake} will take care of the dependencies
@c when defining the rebuild rule, and will also distribute the file
@c automatically.  An inconvenience is that @code{autoconf} will now be
@c rerun each time the version number is bumped, when only
@c @file{configure} had to be rerun in the previous setup.
@c 
ここで,@file{version.m4}には@code{m4_define([VERSION_NUMBER], [1.2])} 
のようなものを含めることができます.この二番目の形式の利点は,
@code{automake}がリビルドルールを定義するとき依存性に注意し,ファイル
も自動的に配布されることです.不便な点は,バージョンナンバーが上昇する
たびに@code{autoconf}が再実行されることで,以前の設定では,
@file{configure}だけが再実行されていました.

@node Options
@c @chapter Changing Automake's Behavior
@chapter Automakeの動作の変更

@c Various features of Automake can be controlled by options in the
@c @file{Makefile.am}.  Such options are applied on a per-@file{Makefile}
@c basis when listed in a special @file{Makefile} variable named
@c @code{AUTOMAKE_OPTIONS}.  They are applied globally to all processed
@c @file{Makefiles} when listed in the first argument of
@c @code{AM_INIT_AUTOMAKE} in @file{configure.ac}.  Currently understood
@c options are:
@c 
Automakeの様々な機能は,@file{Makefile.am}のオプションで制御可能です.
このようなオプションは,@code{AUTOMAKE_OPTIONS}という名前の特別な
@file{Makefile}変数にリストアップすることで,@file{Makefile}ごとを基本
に適用されます.@file{configure.ac}の@code{AM_INIT_AUTOMAKE}の最初の引
数にリストアップすることで,処理されるすべての@file{Makefiles}に大域的
に適用されます.現在理解されるオプションは以下のとおりです.
@vindex AUTOMAKE_OPTIONS

@table @asis
@item @code{gnits}
@itemx @code{gnu}
@itemx @code{foreign}
@itemx @code{cygnus}
@cindex Option, gnits
@cindex Option, gnu
@cindex Option, foreign
@cindex Option, cygnus

@c Set the strictness as appropriate.  The @code{gnits} option also implies
@c @code{readme-alpha} and @code{check-news}.
@c 
適切に厳密さを設定します.@code{gnits}オプションは,
@code{readme-alpha} と@code{check-news}も暗黙に指定します.

@item @code{ansi2knr}
@itemx @code{@var{path}/ansi2knr}
@cindex Option, ansi2knr
@c Turn on automatic de-ANSI-fication.  @xref{ANSI}.  If preceded by a
@c path, the generated @file{Makefile.in} will look in the specified
@c directory to find the @file{ansi2knr} program.  The path should be a
@c relative path to another directory in the same distribution (Automake
@c currently does not check this).
@c 
自動的なde-ANSI-ficationを開始します.@xref{ANSI}.  パスが前置されてい
る場合,生成される@file{Makefile.in}は,@file{ansi2knr}プログラムを見
つけるために指定されたディレクトリを探します.パスは(Automakeは現在こ
れを調査しませんが),同じ配布物内の他のディレクトリへの相対的なパスに
すべきです.

@item @code{check-news}
@cindex Option, check-news
@c Cause @code{make dist} to fail unless the current version number appears
@c in the first few lines of the @file{NEWS} file.
@c 
現在のバージョンナンバーが@file{NEWS}ファイルの最初の数行に無い場合,
@code{make dist}は失敗します.

@item @code{dejagnu}
@cindex Option, dejagnu
@c Cause @code{dejagnu}-specific rules to be generated.  @xref{Tests}.
@c 
@code{dejagnu}特有のルールを生成します.@xref{Tests}.

@item @code{dist-bzip2}
@cindex Option, dist-bzip2
@c Hook @code{dist-bzip2} to @code{dist}.
@c 
@code{dist-bzip2}を@code{dist}にフックします.
@trindex dist-bzip2

@item @code{dist-shar}
@cindex Option, dist-shar
@c Hook @code{dist-shar} to @code{dist}.
@c 
@code{dist-shar}を@code{dist}にフックします.
@trindex dist-shar

@item @code{dist-zip}
@cindex Option, dist-zip
@c Hook @code{dist-zip} to @code{dist}.
@c 
@code{dist-zip}を@code{dist}にフックします.
@trindex dist-zip

@item @code{dist-tarZ}
@cindex Option, dist-tarZ
@c Hook @code{dist-tarZ} to @code{dist}.
@c 
@code{dist-tarZ}を@code{dist}にフックします.
@trindex dist-tarZ

@item @code{filename-length-max=99}
@cindex Option, filename-length-max=99
@trindex filename-length-max=99
@c Abort if filenames longer than 99 characters are found during
@c @code{make dist}.  Such long filenames are generally considered not to
@c be portable in tarballs.  See the @code{tar-v7} and @code{tar-ustar}
@c options below.  This option should be used in the top-level
@c @file{Makefile.am} or as an argument of @code{AM_INIT_AUTOMAKE} in
@c @file{configure.ac}, it will be ignored otherwise.
@c 
ファイル名が99文字以上のものを@code{make dist}中に見つけた場合,中止し
ます.そのような長いファイル名は,一般的に移植性がないtarballだと考え
られます.以下の@code{tar-v7}と@code{tar-ustar}オプションを参照して下
さい.このオプションは,トップレベルの@file{Makefile.am}や
@file{configure.ac}の@code{AM_INIT_AUTOMAKE}の引数で使用されるべきで,
それ以外では無視されるでしょう.

@item @code{no-define}
@cindex Option, no-define
@c This options is meaningful only when passed as an argument to
@c @code{AM_INIT_AUTOMAKE}.  It will prevent the @code{PACKAGE} and
@c @code{VERSION} variables to be @code{AC_DEFINE}d.
@c 
このオプションは,@code{AM_INIT_AUTOMAKE}への引数として渡すときだけ意
味があります.それは@code{PACKAGE}と@code{VERSION}変数が
@code{AC_DEFINE}されることを妨げます.

@item @code{no-dependencies}
@cindex Option, no-dependencies
@c This is similar to using @samp{--include-deps} on the command line, but
@c is useful for those situations where you don't have the necessary bits
@c to make automatic dependency tracking work @xref{Dependencies}.  In this
@c case the effect is to effectively disable automatic dependency tracking.
@c 
これは,コマンドラインで@samp{--include-deps}を使用することに似ていま
すが,自動的な依存追跡の仕事をするために必要なビットが無い状況で役に立
ちます.@xref{Dependencies}.  この状況では,効率的な自動的な依存追跡に
障害を与えます.

@item @code{no-dist}
@cindex Option, no-dist
@c Don't emit any code related to @code{dist} target.  This is useful
@c when a package has its own method for making distributions.
@c 
@code{dist}ターゲットに関連するコードを生成しません.これは,パッケー
ジに独自の配布物を作成する手法があるとき役に立ちます.

@item @code{no-dist-gzip}
@cindex Option, no-dist-gzip
@c Do not hook @code{dist-gzip} to @code{dist}.
@c 
@code{dist-gzip}を@code{dist}にフックしません.
@trindex no-dist-gzip

@item @code{no-exeext}
@cindex Option, no-exeext
@c If your @file{Makefile.am} defines a rule for target @samp{foo}, it
@c will override a rule for a target named @samp{foo$(EXEEXT)}.  This is
@c necessary when @code{EXEEXT} is found to be empty.  However, by
@c default automake will generate an error for this use.  The
@c @code{no-exeext} option will disable this error.  This is intended for
@c use only where it is known in advance that the package will not be
@c ported to Windows, or any other operating system using extensions on
@c executables.
@c 
@file{Makefile.am}でターゲット@samp{foo}に対するルールを定義している場
合,@samp{foo$(EXEEXT)}と指名されているターゲットに対するルールに優先
します.@code{EXEEXT}が空のとき,これが必要です.しかし,デフォルトで,
automakeではこれの使用に対してエラーを発生します.@code{no-exeext}オプ
ションで,このエラーが発生しないようにします.これは,Windowsや実行形
式の拡張子を使用しているそれ以外のすべてのオペレーティングシステムに移
植する予定の無いパッケージだと分かっている場合のみ使用するものです.

@item @code{no-installinfo}
@cindex Option, no-installinfo
@c The generated @file{Makefile.in} will not cause info pages to be built
@c or installed by default.  However, @code{info} and @code{install-info}
@c targets will still be available.  This option is disallowed at
@c @samp{GNU} strictness and above.
@c 
生成された@file{Makefile.in}はデフォルトで,infoページをビルドしたりイ
ンストールしたりしません.しかし,@code{info}と@code{install-info}ター
ゲットは利用可能です.このオプションは@samp{GNU}の厳密さでは拒絶されま
す.
@trindex info
@trindex install-info

@item @code{no-installman}
@cindex Option, no-installman
@c The generated @file{Makefile.in} will not cause man pages to be
@c installed by default.  However, an @code{install-man} target will still
@c be available for optional installation.  This option is disallowed at
@c @samp{GNU} strictness and above.
@c 
生成された@file{Makefile.in}はデフォルトでman pageをインストールしませ
ん.しかし,@code{install-man}ターゲットはオプショナルインストールで利
用可能です.このオプションは@samp{GNU}の厳密さで使用不可能です.
@trindex install-man

@item @code{nostdinc}
@cindex Option, nostdinc
@c This option can be used to disable the standard @samp{-I} options which
@c are ordinarily automatically provided by Automake.
@c 
このオプションは,通常Automakeが自動的に供給する標準的な@samp{-I}オプ
ションを利用不可能にするために使用することが可能です.

@item @code{no-texinfo.tex}
@cindex Option, no-texinfo
@c Don't require @file{texinfo.tex}, even if there are texinfo files in
@c this directory.
@c 
このディレクトリにTexinfoファイルがあっても,@file{texinfo.tex}を必要
としません.

@item @code{readme-alpha}
@cindex Option, readme-alpha
@c If this release is an alpha release, and the file @file{README-alpha}
@c exists, then it will be added to the distribution.  If this option is
@c given, version numbers are expected to follow one of two forms.  The
@c first form is @samp{@var{MAJOR}.@var{MINOR}.@var{ALPHA}}, where each
@c element is a number; the final period and number should be left off for
@c non-alpha releases.  The second form is
@c @samp{@var{MAJOR}.@var{MINOR}@var{ALPHA}}, where @var{ALPHA} is a
@c letter; it should be omitted for non-alpha releases.
@c 
このリリースがアルファリリースで,ファイル@file{README-alpha}が存在す
る場合,それは配布物に加えられます.このオプションが与えられている場合,
バージョンナンバーは次の二つの形式のうちの一つだと期待されます.最初の
形式は@samp{@var{MAJOR}.@var{MINOR}.@var{ALPHA}}で,それぞれの要素が数
字です.最後のピリオドと数字は非アルファのリリースのときに捨てられます.
二番目の形式は@samp{@var{MAJOR}.@var{MINOR}@var{ALPHA}}で,@var{ALPHA}
は文字列です.それは非アルファのリリースのときに取り除かれます.

@item @code{std-options}
@cindex Options, std-options
@cindex make installcheck
@c Make the @code{installcheck} rule check that installed scripts and
@c programs support the @code{--help} and @code{--version} options.
@c This also provides a basic check that the program's
@c run-time dependencies are satisfied after installation.
@c 
@code{installcheck}ルールで,インストールされたスクリプトとプログラム
が,@code{--help}と@code{--version}オプションをサポートしているかどう
かを調査するようにします.これは,プログラムの実行時の依存性がインストー
ル後にも満足しているという基本的な調査も提供します.

@vindex AM_INSTALLCHECK_STD_OPTIONS_EXEMPT
@c In a few situations, programs (or scripts) have to be exempted from this
@c test.  For instance @command{false} (from GNU sh-utils) is never
@c successful, even for @code{--help} or @code{--version}.  You can list
@c such programs in the variable @code{AM_INSTALLCHECK_STD_OPTIONS_EXEMPT}.
@c Programs (not scripts) listed in this variable should be suffixed by
@c @code{$(EXEEXT)} for the sake of Win32 or OS/2.  For instance suppose we
@c build @code{false} as a program but @code{true.sh} as a script, and that
@c neither of them support @code{--help} or @code{--version}:
@c 
状況によって,プログラム(またはスクリプト)でこのテストを免除させる必要
があるかもしれません.例えば,(GNUのsh-utilsの)@command{false}は,
@code{--help}や@code{--version}でさえ,決して成功しません.そのような
プログラムは,変数@code{AM_INSTALLCHECK_STD_OPTIONS_EXEMPT}でリストアッ
プすることが可能です.この変数にリストアップされているプログラム(スク
リプトではない)は,Win32やOS/2に対して@code{$(EXEEXT)}で接尾子が付きま
す.例えば,@code{false}をプログラムとして,@code{true.sh}をスクリプト
としてビルドしようと仮定し,@code{--help}や@code{--version}をどちらも
サポートしないものとします.

@example
AUTOMAKE_OPTIONS = std-options
bin_PROGRAMS = false ...
bin_SCRIPTS = true.sh ...
AM_INSTALLCHECK_STD_OPTIONS_EXEMPT = false$(EXEEXT) true.sh
@end example

@item @code{subdir-objects}
@c If this option is specified, then objects are placed into the
@c subdirectory of the build directory corresponding to the subdirectory of
@c the source file.  For instance if the source file is
@c @file{subdir/file.cxx}, then the output file would be
@c @file{subdir/file.o}.
@c 
このオプションが指定されている場合,オブジェクトはソースファイルのサブ
ディレクトリに対応する,ビルドディレクトリのサブディレクトリに配置され
ます.例えば,ソースファイルが@file{subdir/file.cxx}の場合,出力ファイ
ルは@file{subdir/file.o}になります.

@item @code{tar-v7}
@itemx @code{tar-ustar}
@itemx @code{tar-pax}
@cindex Option, tar-v7
@cindex Option, tar-ustar
@cindex Option, tar-pax
@cindex tar formats
@cindex v7 tar format
@cindex ustar format
@cindex pax format
@trindex tar-v7
@trindex tar-ustar
@trindex tar-pax

@c These three mutually exclusive options select the tar format to use
@c when generating tarballs with @code{make dist}.  (The tar file created
@c is then compressed according to the set of @code{no-dist-gzip},
@c @code{dist-bzip2} and @code{dist-tarZ} options in use.)
@c 
これら三つの排他的なオプションで,@code{make dist}でtarballを生成する
ときのtarのフォーマットを選択します.(作成されるtarファイルは,使用し
ている@code{no-dist-gzip},@code{dist-bzip2},そして@code{dist-tarZ}オ
プションの組合せによって圧縮されます.)

@c These options must be passed as argument to @code{AM_INIT_AUTOMAKE}
@c (@pxref{Macros}) because they can causes new configure check to be
@c performed.  Automake will complain if it sees such option in a
@c @code{AUTOMAKE_OPTIONS} variable.
@c 
これらのオプションは,実行すべき新たなコンフィグレーションの調査を引き
起こすはずなので,@code{AM_INIT_AUTOMAKE}のオプションとして渡す必要が
あります(@pxref{Macros}).@code{AUTOMAKE_OPTIONS}変数でそのようなオプ
ションが見つかる場合,Automakeは文句を言います.

@c @code{tar-v7} selects the old V7 tar format.  This is the historical
@c default.  This antiquated format is understood by all tar
@c implementations and supports filenames with up to 99 characters. When
@c given longer filenames some tar implementations will diagnose the
@c problem while other will generate broken tarballs or use non-portable
@c extensions.  Furthermore, the V7 format cannot store empty
@c directories.  When using this format, consider using the
@c @code{filename-length-max=99} option to catch filenames too long.
@c 
@code{tar-v7}は,古いtarフォーマットを選択します.これは,歴史的なデフォ
ルトです.この古くさいフォーマットは,すべてのtarの実装で解釈でき,99 
文字までのファイル名をサポートしています.与えられるファイル名がそれよ
り長いとき,tarの実装によっては問題を調査しますが,壊れたtarballを生成
したり,移植性の無い拡張子を使用したりするものもあります.さらに,V7 
フォーマットは,空のディレクトリを保持することが不可能です.このフォー
マットを使用しているときは,あまりに長いファイル名を検出する
@code{filename-length-max=99}オプションの使用を検討して下さい.

@c @code{tar-ustar} selects the ustar format defined by POSIX
@c 1003.1-1988.  This format is believed to be old enough to be portable.
@c It fully supports empty directories.  It can stores filenames with up
@c to 256 characters, provided that the filename can be split at
@c directory separator in two parts, first of them being at most 155
@c bytes long. So, in most cases the maximum file name length will be
@c shorter than 256 characters.  However you may run against broken tar
@c implementations that incorrectly handle filenames longer than 99
@c characters (please report them to @email{bug-automake@@gnu.org} so we
@c can document this accurately).
@c 
@code{tar-ustar}は,POSIX 1003.1-1988で定義されているustarフォーマット
を選択します.このフォーマットは,古いものに対して十分移植性があると信
じられています.空のディレクトリも完全にサポートされています.256文字
までのファイル名で保存可能で,ファイル名も,ディレクトリのセパレータで
2つの部分に分割することも可能で,最初のものはほぼ155バイトまで対応して
います.そのため,ほとんどの状況で,最大ファイル名の長さは256文字より
小さくなります.しかし,99文字以上のファイル名の処理が壊れたtarの実装
で実行する可能性もあります(このドキュメントを正確にするため
@email{bug-automake@@gnu.org}にレポートを報告して下さい).

@c @code{tar-pax} selects the new pax interchange format defined by POSIX
@c 1003.1-2001.  It does not limit the length of filenames.  However,
@c this format is very young and should probably be restricted to
@c packages which target only very modern platforms.  There are moves to
@c change the pax format in an upward-compatible way, so this option may
@c refer to a more recent version in the future.
@c 
@code{tar-pax}は,POSIX 1003.1-2001で定義されている,新しいpax交換フォー
マットを選択します.それにはファイル名の長さの制限はありません.しかし,
このフォーマットはまだ新しく,最近のプラットフォームをターゲットとした
パッケージに限定されるでしょう.上位互換の方法としてpaxフォーマット移
行しているので,このオプションは,将来,より新しいバージョンに関係しま
す.

@c @xref{Formats, , Controlling the Archive Format, tar, GNU Tar}, for
@c further discussion about tar formats.
@c 
tarフォーマットの詳細な議論は,@xref{Formats, , Controlling the
Archive Format, tar, GNU Tar}.

@c @code{configure} knows several ways to construct these formats.  It
@c will not abort if it cannot find a tool up to the task (so that the
@c package can still be built), but @code{make dist} will fail.
@c 
@code{configure}でこれらのフォーマットの構成を知る方法はいくつかありま
す.作業終了まで,ツールが分からない場合でも中止しませんが(パッケージ
はビルド可能です),@code{make dist}は失敗するでしょう.

@item @var{version}
@cindex Option, version
@c A version number (e.g. @samp{0.30}) can be specified.  If Automake is not
@c newer than the version specified, creation of the @file{Makefile.in}
@c will be suppressed.
@c 
バージョンナンバー(例えば@samp{0.30})が指定可能です.Automakeが,指定
されているバージョンより新しくない場合,@file{Makefile.in}の作成は行な
われません.

@item @code{-W@var{category}} or @code{--warnings=@var{category}}
@cindex Option, warnings
@c These options behave exactly like their command-line counterpart
@c (@pxref{Invoking Automake}).  This allows you to enable or disable some
@c warning categories on a per-file basis.  You can also setup some warnings
@c for your entire project; for instance try @code{AM_INIT_AUTOMAKE([-Wall])}
@c in your @file{configure.ac}.
@c 
これらのオプションは,コマンドラインに正確に対応するもののように動作し
ます(@pxref{Invoking Automake}).これでファイルごとを基本に,警告のカ
テゴリを有効にしたり無効にしたりすることが可能になります.プロジェクト
全体に警告の設定を行なうことも可能です.例えば,@file{configure.ac}で
@code{AM_INIT_AUTOMAKE([-Wall])}を試してください.

@end table

@c Unrecognized options are diagnosed by @code{automake}.
@c 
認識できないオプションは@code{automake}が判断します.

@c If you want an option to apply to all the files in the tree, you can use
@c the @code{AM_INIT_AUTOMAKE} macro in @file{configure.ac}.
@c @xref{Macros}.
@c 
ツリーの全てのファイルにオプションを適用したい場合,
@file{configure.ac}の@code{AM_INIT_AUTOMAKE}を使用することが可能です.
@xref{Macros}.


@node Miscellaneous
@c @chapter Miscellaneous Rules
@chapter 雑多なルール

@c There are a few rules and variables that didn't fit anywhere else.
@c 
他のどこにも適さない少数のルールと変数があります.

@menu
* Tags::                        Interfacing to etags and mkid
* Suffixes::                    Handling new file extensions
* Multilibs::                   Support for multilibs.
@end menu


@node Tags
@c @section Interfacing to @code{etags}
@section @code{etags}のインターフェース

@cindex TAGS support

@c Automake will generate rules to generate @file{TAGS} files for use with
@c GNU Emacs under some circumstances.
@c 
Automakeは,GNU Emacsで使用する@file{TAGS}ファイルを生成するためのルー
ルを生成する場合もあります.

@trindex tags
@c If any C, C++ or Fortran 77 source code or headers are present, then
@c @code{tags} and @code{TAGS} rules will be generated for the directory.
@c All files listed using the @code{_SOURCES}, @code{_HEADERS}, and
@c @code{_LISP} primaries will be used to generate tags.  Note that
@c generated source files that are not distributed must be declared in
@c variables like @code{nodist_noinst_HEADERS} or
@c @code{nodist_@var{prog}_SOURCES} or they will be ignored.
@c 
C,C++,またはFortran 77のソースコードやヘッダが存在している場合,
@code{tags}と@code{TAGS}ルールがディレクトリに対して生成されます.
@code{_SOURCES},@code{_HEADERS},そして@code{_LISP}プライマリを使用し
てリストアップされているすべてのファイルは,タグを生成されます.配布さ
れることが無い生成されるソースファイルは,@code{nodist_noinst_HEADERS} 
や@code{nodist_@var{prog}_SOURCES}のような変数で宣言する必要があり,そ
うすることでそれらが無視されることに注意して下さい.

@c At the topmost directory of a multi-directory package, a @code{tags}
@c rule will be output which, when run, will generate a @file{TAGS} file
@c that includes by reference all @file{TAGS} files from subdirectories.
@c 
複数のディレクトリがあるパッケージのトップディレクトリで,@code{tags} 
ルールは実行時に出力され,それは実行時に,サブディレクトリにあるすべて
の@file{TAGS}ファイルの参照を含んでいる@file{TAGS}ファイルを生成します.

@c The @code{tags} rule will also be generated if the variable
@c @code{ETAGS_ARGS} is defined.  This variable is intended for use in
@c directories which contain taggable source that @code{etags} does not
@c understand.  The user can use the @code{ETAGSFLAGS} to pass additional
@c flags to @code{etags}; @code{AM_ETAGSFLAGS} is also available for use
@c in @file{Makefile.am}.
@c 
変数@code{ETAGS_ARGS}が定義されている場合,@code{tags}ルールも生成され
ます.この変数は,@code{etags}が理解しないタグを使用しているソースを含
んでいるディレクトリでの使用を考慮しています.ユーザは@code{etags}に追
加のフラグを渡すために@code{ETAGSFLAGS}を使用することが可能です.
@file{Makefile.am}で@code{AM_ETAGSFLAGS}を利用することもできます.
@vindex ETAGS_ARGS
@vindex ETAGSFLAGS
@vindex AM_ETAGSFLAGS

@c Here is how Automake generates tags for its source, and for nodes in its
@c Texinfo file:
@c 
ソースとTexinfoファイルのノードに対するタグをAutomakeで生成する方法は
以下のようになります.

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

@c If you add filenames to @samp{ETAGS_ARGS}, you will probably also
@c want to set @samp{TAGS_DEPENDENCIES}.  The contents of this variable
@c are added directly to the dependencies for the @code{tags} rule.
@c 
@samp{ETAGS_ARGS}にファイル名を加える場合,おそらく
@samp{TAGS_DEPENDENCIES}も設定したいでしょう.この変数の中身は
@code{tags}ルール対する依存性に直接追加されます.
@vindex TAGS_DEPENDENCIES

@c Automake also generates a @code{ctags} rule which can be used to
@c build @command{vi}-style @file{tags} files.  The variable @code{CTAGS}
@c is the name of the program to invoke (by default @samp{ctags});
@c @code{CTAGSFLAGS} can be used by the user to pass additional flags,
@c and @code{AM_CTAGSFLAGS} can be used by the @file{Makefile.am}.
@c 
Automakeは,@command{vi}形式の@file{tags}ファイルのビルドで使用される,
@code{ctags}ルールを生成します.変数@code{CTAGS}は,呼び出されるプログ
ラムの名前です(デフォルトは@samp{ctags}).@code{CTAGSFLAGS}は,ユーザ
が追加フラグを渡すために使用され,@code{AM_CTAGSFLAGS}は
@file{Makefile.am}で使用されます.

@c Automake will also generate an @code{ID} rule which will run
@c @code{mkid} on the source.  This is only supported on a
@c directory-by-directory basis.
@c 
Automakeは,@code{mkid}をソース上で実行する@code{ID}ルールも生成します.
これはディレクトリ単位に基づくサポートだけです.
@trindex id

@c Automake also supports the @uref{http://www.gnu.org/software/global/,
@c GNU Global Tags program}.  The @code{GTAGS} rule runs Global Tags
@c automatically and puts the result in the top build directory.  The
@c variable @code{GTAGS_ARGS} holds arguments which are passed to
@c @code{gtags}.
@c 
Automakeは@uref{http://www.gnu.org/software/global/, GNU Global Tags
program}もサポートします.@code{GTAGS}ルールは,自動的にGlobal Tagを実
行し,結果をビルドディレクトリに書き込みます.変数@code{GTAGS_ARGS}は,
@code{gtags}に渡す引数を保持しています.
@vindex GTAGS_ARGS


@node Suffixes
@c @section Handling new file extensions
@section 新しいファイル拡張子の取り扱い

@cindex Adding new SUFFIXES
@cindex SUFFIXES, adding
@vindex SUFFIXES

@c It is sometimes useful to introduce a new implicit rule to handle a file
@c type that Automake does not know about.
@c 
Automakeが知らないファイル形式を処理するために,新しい暗黙のルールを導
入することが役に立つこともあります.

@c For instance, suppose you had a compiler which could compile @samp{.foo}
@c files to @samp{.o} files.  You would simply define an suffix rule for
@c your language:
@c 
例えば,@samp{.foo}ファイルを@samp{.o}ファイルにコンパイルするコンパイ
ラがあると仮定します.その言語に対する接尾子ルールを単純に定義するでしょ
う.

@example
.foo.o:
        foocc -c -o $@@ $<
@end example

@c Then you could directly use a @samp{.foo} file in a @samp{_SOURCES}
@c variable and expect the correct results:
@c 
そして,@samp{_SOURCES}変数で@samp{.foo}ファイルを直接使用し,正しい結
果が期待されるでしょう.

@example
bin_PROGRAMS = doit
doit_SOURCES = doit.foo
@end example

@c This was the simpler and more common case.  In other cases, you will
@c have to help Automake to figure which extensions you are defining your
@c suffix rule for.  This usually happens when your extensions does not
@c start with a dot.  Then, all you have to do is to put a list of new
@c suffixes in the @code{SUFFIXES} variable @strong{before} you define your
@c implicit rule.
@c 
これはより簡単で,より一般的な状況です.それ以外の状況では,定義してい
るサフィックスルールを,Automakeが理解する手助けが必要です.通常これは,
拡張子がドットで始まらないときに生じます.そのときにしなければならない
ことは,暗黙のルールを定義する@strong{前に},新しい接尾子のリストを
@code{SUFFIXES} 変数に書き込むことです.

@c For instance the following definition prevents Automake to misinterpret
@c @samp{.idlC.cpp:} as an attempt to transform @samp{.idlC} into
@c @samp{.cpp}.
@c 
例えば,以下の定義で,Automakeが誤解して,@samp{.idlC.cpp:}で
@samp{.idlC}を@samp{.cpp}に変換する試行をしないようにします.

@example
SUFFIXES = .idl C.cpp
.idlC.cpp:
        # whatever
@end example

@c As you may have noted, the @code{SUFFIXES} variable behaves like the
@c @code{.SUFFIXES} special target of @code{make}.  You should not touch
@c @code{.SUFFIXES} yourself, but use @code{SUFFIXES} instead and let
@c Automake generate the suffix list for @code{.SUFFIXES}.  Any given
@c @code{SUFFIXES} go at the start of the generated suffixes list, followed
@c by Automake generated suffixes not already in the list.
@c 
注意していると思いますが,@code{SUFFIXES}変数は@code{make}の
@code{.SUFFIXES}特殊ターゲットのように動作します.@code{.SUFFIXES}を独
自にいじくるべきではなく,その代わりに@code{SUFFIXES}を使用しAutomake 
が@code{.SUFFIXES}に対する接尾子リストを生成するようにすべきです.与え
られた全ての@code{SUFFIXES}は生成された接尾子リストの最初に書かれ,
Automakeが生成するまだリストに無い接尾子が続きます.

@node Multilibs
@c @section Support for Multilibs
@section Multilibのサポート

@c Automake has support for an obscure feature called multilibs.  A
@c @dfn{multilib} is a library which is built for multiple different ABIs
@c at a single time; each time the library is built with a different target
@c flag combination.  This is only useful when the library is intended to
@c be cross-compiled, and it is almost exclusively used for compiler
@c support libraries.
@c 
Automakeには,multilibと呼ばれているあまり知られていない機能のサポート
があります.@dfn{multilib}は,一度に複数の異なるABIに対してビルドされ
るライブラリです.毎回,ライブラリが異なるターゲットフラグの組み合わせ
でビルドされます.これは,ライブラリがクロスコンパイルを目的としていて,
コンパイラがサポートしているライブラリに対して,ほとんど排他的に使用さ
れるときだけ役に立ちます.

@c The multilib support is still experimental.  Only use it if you are
@c familiar with multilibs and can debug problems you might encounter.
@c 
multilibのサポートはまだ実験中です.multilibを理解していて,遭遇した問
題をデバッグすることが可能な場合のみ,それを使用してください.


@node Include
@c @chapter Include
@chapter インクルード

@cmindex include
@cindex Including Makefile fragment
@cindex Makefile fragment, including

@c Automake supports an @code{include} directive which can be used to
@c include other @file{Makefile} fragments when @code{automake} is run.
@c Note that these fragments are read and interpreted by @code{automake},
@c not by @code{make}.  As with conditionals, @code{make} has no idea that
@c @code{include} is in use.
@c 
Automakeは,@code{automake}が実行されるときに,他の断片的な
@file{Makefile}をインクルードするために使用可能な,@code{include}指示
語をサポートします.これらの断片は,@code{make}ではなく@code{automake}
で読み込まれ解釈されることに注意してください.条件文同様,@code{make}
には@code{include}を使用する能力はありません.

@c There are two forms of @code{include}:
@c 
@code{include}には,二つの書式があります.

@table @code
@item include $(srcdir)/file
@c Include a fragment which is found relative to the current source
@c directory.
@c 
現在のソースディレクトリに相対的なところで見つかった断片をインクルード
します.

@item include $(top_srcdir)/file
@c Include a fragment which is found relative to the top source directory.
@c 
トップソースディレクトリに相対的なところで見つかった断片をインクルード
します.
@end table

@c Note that if a fragment is included inside a conditional, then the
@c condition applies to the entire contents of that fragment.
@c 
断片が条件文を含んでいる場合,条件文は断片の内容全体に適用されることに
注意してください.

@c Makefile fragments included this way are always distributed because
@c there are needed to rebuild @file{Makefile.in}.
@c 
@file{Makefile.in}をリビルドする必要があるので,この方法でインクルード
されるMakefileの断片は常に配布されます.

@node Conditionals
@c @chapter Conditionals
@chapter 条件文

@cindex Conditionals

@c Automake supports a simple type of conditionals.
@c 
Automakeは単純な形式の条件文をサポートします.

@cvindex AM_CONDITIONAL
@c Before using a conditional, you must define it by using
@c @code{AM_CONDITIONAL} in the @code{configure.ac} file (@pxref{Macros}).
@c 
条件文を使用する前に,@code{configure.ac}ファイルで
@code{AM_CONDITIONAL}を使用してそれを定義する必要があります
(@pxref{Macros}).

@defmac AM_CONDITIONAL (@var{conditional}, @var{condition})
@c The conditional name, @var{conditional}, should be a simple string
@c starting with a letter and containing only letters, digits, and
@c underscores.  It must be different from @samp{TRUE} and @samp{FALSE}
@c which are reserved by Automake.
@c 
条件名@var{conditional}は,文字で始まり,文字,数字,そしてアンダース
コアのみを含む単純な文字列です.Automakeが@samp{TRUE}と@samp{FALSE}の
どちらを保持しているかで異なっているはずです.

@c The shell @var{condition} (suitable for use in a shell @code{if}
@c statement) is evaluated when @code{configure} is run.  Note that you
@c must arrange for @emph{every} @code{AM_CONDITIONAL} to be invoked every
@c time @code{configure} is run -- if @code{AM_CONDITIONAL} is run
@c conditionally (e.g., in a shell @code{if} statement), then the result
@c will confuse automake.
@c 
シェルの@var{condition}(シェルの@code{if}文で使用されるのに適切なもの) 
は,@code{configure}が実行されるときに評価されます.@emph{すべての}
@code{AM_CONDITIONAL}が毎回@code{configure}の実行で呼び出されるように
調整する必要があります -- @code{AM_CONDITIONAL}が条件付き(例えば,シェ
ルの@code{if}文)で実行される場合,結果としてautomakeが混乱します.
@end defmac

@cindex --enable-debug, example
@cindex Example conditional --enable-debug
@cindex Conditional example,  --enable-debug

@c Conditionals typically depend upon options which the user provides to
@c the @code{configure} script.  Here is an example of how to write a
@c conditional which is true if the user uses the @samp{--enable-debug}
@c option.
@c 
条件文は一般的に,@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

@c Here is an example of how to use that conditional in @file{Makefile.am}:
@c 
@file{Makefile.am}でその条件文を使用する方法の例は以下のようになります.

@cmindex if
@cmindex endif
@cmindex else

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

@c This trivial example could also be handled using EXTRA_PROGRAMS
@c (@pxref{Conditional Programs}).
@c 
この簡単な例で,EXTRA_PROGRAMSを使用しているものを扱うことも可能でしょ
う(@pxref{Conditional Programs}).

@c You may only test a single variable in an @code{if} statement, possibly
@c negated using @samp{!}.  The @code{else} statement may be omitted.
@c Conditionals may be nested to any depth.  You may specify an argument to
@c @code{else} in which case it must be the negation of the condition used
@c for the current @code{if}.  Similarly you may specify the condition
@c which is closed by an @code{end}:
@c 
@code{if}文で,@samp{!}を使用した否定も可能な,単一の変数のみを調査し
たいかもしれません.@code{else}文は省略可能です.条件文は任意の深さに
ネスト可能です.@code{else}に引数を指定することも可能ですが,いずれの
場合でも,現在の@code{if}に対して使用される条件の否定となっている必要
があります.同様に,@code{end}で閉じられた条件を指定することも可能です.

@example
if DEBUG
DBG = debug
else !DEBUG
DBG =
endif !DEBUG
@end example

@noindent
@c Unbalanced conditions are errors.
@c 
対称性のないの条件文はエラーとなります.

@c Note that conditionals in Automake are not the same as conditionals in
@c GNU Make.  Automake conditionals are checked at configure time by the
@c @file{configure} script, and affect the translation from
@c @file{Makefile.in} to @file{Makefile}.  They are based on options passed
@c to @file{configure} and on results that @file{configure} has discovered
@c about the host system.  GNU Make conditionals are checked at @code{make}
@c time, and are based on variables passed to the make program or defined
@c in the @file{Makefile}.
@c 
Automakeの条件文はGNU Makeの条件文とは同じでないことに注意してください.
Automakeの条件文は,configure時に@file{configure}スクリプトでチェック
され,@file{Makefile.in}から@file{Makefile}への変換に影響を与えます.
それらは,@file{configure}に渡すオプションと,@file{configure}がホスト
システムについて発見した結果に基づきます.GNU Makeの条件文は,
@code{make}時に調査され,makeプログラムに渡された,あるいは
@file{Makefile}で定義された変数に基づいています.

@c Automake conditionals will work with any make program.
@c 
Automakeの条件文は,どんなmakeプログラムでも動作します.


@node Gnits
@c @chapter The effect of @code{--gnu} and @code{--gnits}
@chapter @code{--gnu}と@code{--gnits}の効果

@cindex --gnu, required files
@cindex --gnu, complete description

@c The @samp{--gnu} option (or @samp{gnu} in the @samp{AUTOMAKE_OPTIONS}
@c variable) causes @code{automake} to check the following:
@c 
@samp{--gnu}オプション(あるいは@samp{AUTOMAKE_OPTIONS}変数での
@samp{gnu})で,@code{automake}は以下のことを調査します.

@itemize @bullet
@item
@c The files @file{INSTALL}, @file{NEWS}, @file{README}, @file{AUTHORS},
@c and @file{ChangeLog}, plus one of @file{COPYING.LIB}, @file{COPYING.LESSER}
@c or @file{COPYING}, are required at the topmost directory of the package.
@c 
@file{INSTALL},@file{NEWS},@file{README},@file{AUTHORS},そして
@file{ChangeLog}と,@file{COPYING.LIB},@file{COPYING.LESSER},または
@file{COPYING}のいずれかもう一つのファイルがパッケージのトップディレク
トリにあることが必要です.

@item
@c The options @samp{no-installman} and @samp{no-installinfo} are
@c prohibited.
@c 
@samp{no-installman}と@samp{no-installinfo}オプションは使用できません.
@end itemize

@c Note that this option will be extended in the future to do even more
@c checking; it is advisable to be familiar with the precise requirements
@c of the GNU standards.  Also, @samp{--gnu} can require certain
@c non-standard GNU programs to exist for use by various maintainer-only
@c rules; for instance in the future @code{pathchk} might be required for
@c @samp{make dist}.
@c 
このオプションは,それ以上の調査を行なうため将来拡張されることでしょう.
GNU標準の正確な必要条件に精通することを勧めます.また,@samp{--gnu}は,
様々な管理者専用のルールで使用するために存在する,特定のGNU非標準のプ
ログラムを要求するはずです.例えば将来は,@code{pathchk}が@samp{make
dist}に対して要求されるかもしれません.

@cindex --gnits, complete description

@c The @samp{--gnits} option does everything that @samp{--gnu} does, and
@c checks the following as well:
@c 
@samp{--gnits}オプションは,@samp{--gnu}が行なうすべての調査に加え以下
のことも調査します.

@itemize @bullet
@item
@c @samp{make installcheck} will check to make sure that the @code{--help}
@c and @code{--version} really print a usage message and a version string,
@c respectively.  This is the @code{std-options} option (@pxref{Options}).
@c 
@samp{make installcheck}は,@code{--help}と@code{--version}が,それぞ
れ本当に利用方法のメッセージとバージョン文字列を確実に出力することを調
査します.これは,@code{std-options}オプションです(@pxref{Options}).

@item
@c @samp{make dist} will check to make sure the @file{NEWS} file has been
@c updated to the current version.
@c 
@samp{make dist}を,@file{NEWS}ファイルが現在のバージョンに更新された
ことを確認するために調査します.

@item
@c @samp{VERSION} is checked to make sure its format complies with Gnits
@c standards.
@c 
@samp{VERSION}は,その書式ががGnits standardに従っていることを確認する
ために調査されます.
@c FIXME xref when standards are finished

@item
@cindex README-alpha
@c If @samp{VERSION} indicates that this is an alpha release, and the file
@c @file{README-alpha} appears in the topmost directory of a package, then
@c it is included in the distribution.  This is done in @samp{--gnits}
@c mode, and no other, because this mode is the only one where version
@c number formats are constrained, and hence the only mode where Automake
@c can automatically determine whether @file{README-alpha} should be
@c included.
@c 
これがアルファリリースだということを@samp{VERSION}が示していて,ファイ
ル@file{README-alpha}がパッケージのトップディレクトリにある場合,それ
は配布物に含められます.@samp{--gnits}モードはバージョンナンバーの書式
に制限がある唯一のものであり,そのためAutomakeが自動的に
@file{README-alpha}を含めることを決定することが可能な唯一のモードなの
で,これは@samp{--gnits}モードではなされますが他ではなされません.

@item
@c The file @file{THANKS} is required.
@c 
ファイル@file{THANKS}が必要です.
@end itemize


@node Cygnus
@c @chapter The effect of @code{--cygnus}
@chapter @code{--cygnus}の効果

@cindex Cygnus strictness

@c Some packages, notably GNU GCC and GNU gdb, have a build environment
@c originally written at Cygnus Support (subsequently renamed Cygnus
@c Solutions, and then later purchased by Red Hat).  Packages with this
@c ancestry are sometimes referred to as ``Cygnus'' trees.
@c 
特にGNU GCCとGNU gdbのようなパッケージには,Cygnus Support(その後,
Cygnus Solutionsに名前が変更され,その後で Red Hatに買収されました)で
通常書かれているビルド環境変数があります.この系統のパッケージは,
``Cygnus''ツリーとして述べられるときもあります.

@c A Cygnus tree has slightly different rules for how a @file{Makefile.in}
@c is to be constructed.  Passing @samp{--cygnus} to @code{automake} will
@c cause any generated @file{Makefile.in} to comply with Cygnus rules.
@c 
Cygnusツリーには,@file{Makefile.in}を構築する方法に対して,わずかに異
なったルールがあります.@code{automake}へ@samp{--cygnus}を渡すことで,
生成されるすべての@file{Makefile.in}はCygnus規則に従います.

@c Here are the precise effects of @samp{--cygnus}:
@c 
@samp{--cygnus}の正確な効果は以下のようになっています.

@itemize @bullet
@item
@c Info files are always created in the build directory, and not in the
@c source directory.
@c 
Infoファイルは,ソースディレクトリでではなく,常にビルドディレクトリで
作成されます.

@item
@c @file{texinfo.tex} is not required if a Texinfo source file is
@c specified.  The assumption is that the file will be supplied, but in a
@c place that Automake cannot find.  This assumption is an artifact of how
@c Cygnus packages are typically bundled.
@c 
@file{texinfo.tex}は,Texinfoソースファイルが指定されている場合でも,
要求されません.ファイルは提供されているのですが,Automakeが見つけられ
ない場所にあると仮定します.この仮定は,一般的にCygnusパッケージをバン
ドルする方法として人工的に作られたものです.

@item
@c @samp{make dist} is not supported, and the rules for it are not
@c generated.  Cygnus-style trees use their own distribution mechanism.
@c 
@samp{make dist}はサポートされておらず,そのルールは生成されません.
Cygnus形式のツリーでは独自の配布メカニズムを使用します.

@item
@c Certain tools will be searched for in the build tree as well as in the
@c user's @samp{PATH}.  These tools are @code{runtest}, @code{expect},
@c @code{makeinfo} and @code{texi2dvi}.
@c 
ユーザの@samp{PATH}同様にビルドツリーでも特定のツールを捜します.これ
らのツールは,@code{runtest},@code{expect},@code{makeinfo},そして
@code{texi2dvi}です.

@item
@c @code{--foreign} is implied.
@c 
@code{--foreign}を暗黙に指定します.

@item
@c The options @samp{no-installinfo} and @samp{no-dependencies} are
@c implied.
@c 
オプション@samp{no-installinfo}と@samp{no-dependencies}を暗黙に指定し
ます.

@item
@c The macros @samp{AM_MAINTAINER_MODE} and @samp{AM_CYGWIN32} are
@c required.
@c 
マクロ@samp{AM_MAINTAINER_MODE}と@samp{AM_CYGWIN32}が要求されます.

@item
@c The @code{check} target doesn't depend on @code{all}.
@c 
@code{check}ターゲットは@code{all}に依存しません.
@end itemize

@c GNU maintainers are advised to use @samp{gnu} strictness in preference
@c to the special Cygnus mode.  Some day, perhaps, the differences between
@c Cygnus trees and GNU trees will disappear (for instance, as GCC is made
@c more standards compliant).  At that time the special Cygnus mode will be
@c removed.
@c 
GNU管理者は,特別なCygnusモードではなく@samp{gnu}の厳密さを使用してく
ださい.いつかはおそらく,CygnusツリーとGNUツリーの間の差が(例えば,
GCCがより標準に準拠するように)なくなることでしょう.そのときは,特殊な
Cygnus モードは削除されるでしょう.


@node Not Enough
@c @chapter When Automake Isn't Enough
@chapter Automakeが不十分なとき

@c In some situations, where Automake is not up to one task, one has to
@c resort to handwritten rules or even handwritten @file{Makefile}s.
@c 
状況によっては,Automakeだけで作業をまかなえず,手書きのルールや手書き
の@file{Makefile}といった手段を利用します.

@menu
* Extending::                   Adding new rules or overriding existing ones.
* Third-Party Makefiles::       Integrating Non-Automake @file{Makefile}s.
@end menu

@node Extending
@c @section Extending Automake Rules
@section Automakeルールの拡張

@c With some minor exceptions (like @code{_PROGRAMS} variables being
@c rewritten to append @code{$(EXEEXT)}), the contents of a
@c @file{Makefile.am} is copied to @file{Makefile.in} verbatim.
@c 
(@code{_PROGRAMS}のような変数は@code{$(EXEEXT)}が追加されて書き直され
るといった)わずかな例外はありますが,@file{Makefile.am}の内容は
@file{Makefile.in}にそのままコピーされます.

@cindex copying semantics

@c These copying semantics means that many problems can be worked around
@c by simply adding some @code{make} variables and rules to
@c @file{Makefile.am}.  Automake will ignore these additions.
@c 
これらのコピーの意味は,単純にいくつかの@code{make}変数とルールを
@file{Makefile.am}に追加することで,多くの問題が解決可能だということを
意味します.Automakeはこれらの追加を無視します.

@cindex conflicting definitions
@cindex rules, conflicting
@cindex variables, conflicting
@cindex definitions, conflicts

@c Since a @file{Makefile.in} is built from data gathered from three
@c different places (@file{Makefile.am}, @file{configure.ac}, and
@c @command{automake} itself), it is possible to have conflicting
@c definitions of rules or variables.  When building @file{Makefile.in}
@c the following priorities are respected by @command{automake} to ensure
@c the user always have the last word.  User defined variables in
@c @file{Makefile.am} have priority over variables @code{AC_SUBST}ed from
@c @file{configure.ac}, and @code{AC_SUBST}ed variables have priority
@c over @command{automake}-defined variables.  As far rules are
@c concerned, a user-defined rule overrides any
@c @command{automake}-defined rule for the same target.
@c 
@file{Makefile.in}は,三つの異なる場所(@file{Makefile.am},
@file{configure.ac},そして@command{automake}自身)からデータを集めてビ
ルドされるので,ルールや変数の定義が衝突する可能性があります.
@file{Makefile.in}をビルドするとき,ユーザが最後の単語を利用することを
保証するために,@command{automake}に関連する優先順位に従います.
@file{Makefile.am}でユーザが定義した変数は,@file{configure.ac}で
@code{AC_SUBST}した変数より優先され,@code{AC_SUBST}された変数は
@command{automake}が定義した変数より優先されます.同様にルールも関連し
て,ユーザ定義のルールは@command{automake}が定義した同じターゲットに対
するルールに優先されます.

@cindex overriding rules
@cindex overriding semantics
@cindex rules, overriding

@c These overriding semantics make it possible to fine tune some default
@c settings of Automake, or replace some of its rules.  Overriding
@c Automake rules is often inadvisable, particularly in the topmost
@c directory of a package with subdirectories.  The @code{-Woverride}
@c option (@pxref{Invoking Automake}) comes handy to catch overridden
@c definitions.
@c 
これらのオーバーライドの意味は,Automakeのデフォルトの設定をうまく調整
したり,そのルールを置換することを可能にします.Automakeのルールをオー
バーライドすることはあまり勧められず,特にサブディレクトリがあるパッケー
ジの最上位のディレクトリではそうです.@code{-Woverride}オプション
(@pxref{Invoking Automake})で,オーバーライドしている定義が簡単に捕え
られます.

@c Note that Automake does not make any difference between rules with
@c commands and rules that only specify dependencies.  So it is not
@c possible to append new dependencies to an @code{automake}-defined
@c target without redefining the entire rule.
@c 
Automakeには,コマンドを用いたルールと依存性を指定するだけのルールに差
異がないことに注意して下さい.@code{automake}が定義したターゲットに,
ルール全体を定義することなく新しい依存性を追加することは不可能です.

@cindex -local targets
@cindex local targets

@c However, various useful targets have a @samp{-local} version you can
@c specify in your @file{Makefile.in}.  Automake will supplement the
@c standard target with these user-supplied targets.
@c 
しかし,様々な有用なターゲットには,@file{Makefile.in}で指定可能な,
@samp{-local}バージョンがあります.Automakeはこれらのユーザが提供する
ターゲットを用いて標準ターゲットを補足します.

@trindex  all
@trindex  all-local
@trindex  info
@trindex  info-local
@trindex  dvi
@trindex  dvi-local
@trindex  ps
@trindex  ps-local
@trindex  pdf
@trindex  pdf-local
@trindex  html
@trindex  html-local
@trindex  check
@trindex  check-local
@trindex  install
@trindex  install-data-local
@trindex  install-exec
@trindex  install-exec-local
@trindex  uninstall
@trindex  uninstall-local
@trindex  mostlyclean
@trindex  mostlyclean-local
@trindex  clean
@trindex  clean-local
@trindex  distclean
@trindex  distclean-local
@trindex  installdirs
@trindex  installdirs-local
@trindex  installcheck
@trindex  installcheck-local

@c The targets that support a local version are @code{all}, @code{info},
@c @code{dvi}, @code{ps}, @code{pdf}, @code{html}, @code{check},
@c @code{install-data}, @code{install-exec}, @code{uninstall},
@c @code{installdirs}, @code{installcheck} and the various @code{clean} targets
@c (@code{mostlyclean}, @code{clean}, @code{distclean}, and
@c @code{maintainer-clean}).  Note that there are no
@c @code{uninstall-exec-local} or @code{uninstall-data-local} targets; just
@c use @code{uninstall-local}.  It doesn't make sense to uninstall just
@c data or just executables.
@c 
ローカルバージョンをサポートするターゲットは,@code{all},@code{info},
@code{dvi},@code{ps},@code{pdf},@code{html},@code{check},
@code{install-data}, @code{install-exec},@code{uninstall},
@code{installdirs},@code{installcheck},そして様々な@code{clean}ター
ゲット(@code{mostlyclean},@code{clean},@code{distclean},そして
@code{maintainer-clean})です.@code{uninstall-exec-local}や
@code{uninstall-data-local}ターゲットが無いことに注意してください.
@code{uninstall-local}だけを使用してください.データだけ,あるいは実行
可能プログラムだけをアンインストールすることには意味がありません.

@c For instance, here is one way to install a file in @file{/etc}:
@c 
例えば,ファイルを@file{/etc}にインストールする一つの方法は,以下のよ
うになります.

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

@cindex -hook targets
@cindex hook targets

@c Some rule also have a way to run another rule, called a @dfn{hook},
@c after their work is done.  The hook is named after the principal target,
@c with @samp{-hook} appended.  The targets allowing hooks are
@c @code{install-data}, @code{install-exec}, @code{uninstall}, @code{dist},
@c and @code{distcheck}.
@c 
ルールには,@dfn{hook}と呼ばれる,その仕事が終った後にもう一つのルール
を実行する方法もあります.フックは,主要なターゲットに@samp{-hook} を
追加して命名します.フックが可能なターゲットは,@code{install-data},
@code{install-exec},@code{uninstall},@code{dist},そして
@code{distcheck}です.
@trindex install-data-hook
@trindex install-exec-hook
@trindex uninstall-hook
@trindex dist-hook

@c For instance, here is how to create a hard link to an installed program:
@c 
例えば,インストールしたプログラムにハードリンクを作成する方法は,以下
のようになります.

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

@c Although cheaper and more portable than symbolic links, hard links
@c will not work everywhere (for instance OS/2 does not have
@c @command{ln}).  Ideally you should fall back to @code{cp -p} when
@c @code{ln} does not work.  An easy way, if symbolic links are
@c acceptable to you, is to add @code{AC_PROG_LN_S} to
@c @file{configure.ac} (@pxref{Particular Programs, , Particular Program
@c Checks, autoconf, The Autoconf Manual}) and use @code{$(LN_S)} in
@c @file{Makefile.am}.
@c 
安っぽいけれど,シンボリックリンクより移植性の高いハードリンクは,どこ
ででも動作するわけではありません(例えば,OS/2には@command{ln}がありま
せん).理想としては,@code{ln}が動作しないときは@code{cp -p}に逆戻りす
べきです.簡単な方法は,シンボリックリンクを受け入れる場合,
@file{configure.ac}に@code{AC_PROG_LN_S}を追加し(@pxref{Particular
Programs, , Particular Program Checks, autoconf, The Autoconf Manual}),
@file{Makefile.am}で@code{$(LN_S)}を使用して下さい.

@cindex versioned binaries, installing
@cindex installing versioned binaries
@cindex LN_S example
@c For instance, here is how you could install a versioned copy of a
@c program using @code{$(LN_S)}:
@c 
例えば,以下では,@code{$(LN_S)}を用いてプログラムのコピーバージョンの
インストールを可能にする方法です.

@example
install-exec-hook:
        cd $(DESTDIR)$(bindir) && \
          mv -f prog$(EXEEXT) prog-$(VERSION)$(EXEEXT) && \
          $(LN_S) prog-$(VERSION)$(EXEEXT) prog$(EXEEXT)
@end example

@c Note that we rename the program so that a new version will erase the
@c symbolic link, not the real binary.  Also we @code{cd} into the
@c destination directory in order to create relative links.
@c 
我々は,新しいバージョンがシンボリックリンクを削除し,本当のバイナリを
削除しないように,プログラムの名前を変更していることに注意して下さい.
また,我々は,相対リンクを作成するため,コピー先のディレクトリに
@code{cd}しています.
@c FIXME should include discussion of variables you can use in these
@c rules

@node Third-Party Makefiles
@c @section Third-Party @file{Makefile}s
@section サードパーティーの@file{Makefile}

@cindex Third-party packages, interfacing with
@cindex Interfacing with third-party packages

@c In most projects all @file{Makefile}s are generated by Automake.  In
@c some cases, however, projects need to embed subdirectories with
@c handwritten @file{Makefile}s.  For instance one subdirectory could be
@c a third-party project with its own build system, not using Automake.
@c 
ほとんどのプロジェクトで,すべての@file{Makefile}はAutomakeで生成され
ます.しかし,状況によっては手書きの@file{Makefile}をサブディレクトリ
に配置する必要があるプロジェクトもあります.例えば,あるディレクトリは
独自のビルドシステムを用いたサードパーティーのプロジェクトで,それ以外
はAutomakeを使用していることもあるでしょう.

@c It is possible to list arbitrary directories in @code{SUBDIRS} or
@c @code{DIST_SUBDIRS} provided each of these directories has a
@c @file{Makefile} that recognizes all the following recursive targets.
@c 
以下の再帰的なターゲットをすべて認識する@file{Makefile}があるディレク
トリであれば,任意のディレクトリを@code{SUBDIRS}や@code{DIST_SUBDIRS}
にリストアップすることが可能です.

@cindex recursive targets and third-party @file{Makefile}s
@c When a user runs one of these targets, that target is run recursively
@c in all subdirectories.  This is why it is important that even
@c third-party @file{Makefile}s support them.
@c 
ユーザが以下のターゲットを実行したとき,ターゲットはすべてのサブディレ
クトリで再帰的に実行されます.これは,サードパーティーの
@file{Makefile}がそれらをサポートしていることが重要である理由です.

@table @code
@item all
@c Compile the entire package.  This is the default target in
@c Automake-generated @file{Makefile}s, but it does not need to be the
@c default in third-party @file{Makefile}s.
@c 
パッケージを完全にコンパイルします.これは,Automakeが生成する
@file{Makefile}ではデフォルトのターゲットですが,サードパーティーの
@file{Makefile}ではデフォルトである必要はありません.

@item distdir
@trindex distdir
@vindex distdir
@vindex top_distdir
@c Copy files to distribute into @code{$(distdir)}, before a tarball is
@c constructed.  Of course this target is not required if the
@c @code{no-dist} option (@pxref{Options}) is used.
@c 
tarballが構築される前に@code{$(distdir)}に配布すべきファイルをコピーし
ます.もちろん,このターゲットも@code{no-dist}オプション
(@pxref{Options}が使用されている場合は不要です.

@c The variables @code{$(top_distdir)} and @code{$(distdir)}
@c (@pxref{Dist}) will be passed from the outer package to the subpackage
@c when the @code{distdir} target is invoked.  These two variables have
@c been adjusted for the directory which is being recursed into, so they
@c are ready to use.
@c 
変数@code{$(top_distdir)}と@code{$(distdir)}(@pxref{Dist})は,
@code{distdir}ターゲットが呼び出されるとき,サブパッケージとなる外部パッ
ケージから渡されます.これら二つの変数は,再帰的になっているディレクト
リで調整されているので,すでに使用されています.

@item install
@itemx install-data
@itemx install-exec
@itemx uninstall
@c Install or uninstall files (@pxref{Install}).
@c 
ファイルをインストールしたりアンインストールしたりします
(@pxref{Install}).

@item install-info
@c Install only the Texinfo documentation (@pxref{Texinfo}).
@c 
Texinfoドキュメントだけをインストールします(@pxref{Texinfo}).

@item installdirs
@c Create install directories, but do not install any files.
@c 
インストールディレクトリを作成しますが,ファイルはインストールしません.

@item check
@itemx installcheck
@c Check the package (@pxref{Tests}).
@c 
パッケージを調査します(@pxref{Tests}).

@item mostlyclean
@itemx clean
@itemx distclean
@itemx maintainer-clean
@c Cleaning rules (@pxref{Clean}).
@c 
クリーンルールです(@pxref{Clean}).

@item dvi
@itemx pdf
@itemx ps
@itemx info
@itemx html
@c Build the documentation in various formats (@pxref{Texinfo}).
@c 
さまざまな書式のドキュメントをビルドします(@pxref{Texinfo}).

@item tags
@itemx ctags
@c Build @code{TAGS} and @code{CTAGS} (@pxref{Tags}).
@c 
@code{TAGS}と@code{CTAGS}をビルドします(@pxref{Tags}).
@end table

@c If you have ever used Gettext in a project, this is a good example of
@c how third-party @file{Makefile}s can be used with Automake.  The
@c @file{Makefile}s @command{gettextize} puts in the @file{po/} and
@c @file{intl/} directories are handwritten @file{Makefile}s that
@c implement all these targets.  That way they can be added to
@c @code{SUBDIRS} in Automake packages.
@c 
プロジェクトでGettextを使用したことがある場合,これはサードパーティー
の@file{Makefile}がAutomakeが使用可能だという良い例になります.
@file{po/}と@file{intl/}にある@command{gettextize}された
@file{Makefile}は,これらすべてのターゲットを実装している手書きの
@file{Makefile}です.すなわち,Automakeパッケージの@code{SUBDIRS}に追
加することが可能です.

@c Directories which are only listed in @code{DIST_SUBDIRS} but not in
@c @code{SUBDIRS} need only the @code{distclean},
@c @code{maintainer-clean}, and @code{distdir} rules (@pxref{Conditional
@c Subdirectories}).
@c 
@code{DIST_SUBDIRS}だけでリストアップされていて,@code{SUBDIRS}でリス
トアップされていないディレクトリは,@code{distclean},
@code{maintainer-clean},そして@code{distdir}ルールだけが必要です
(@pxref{Conditional Subdirectories}).

@c Usually, many of these rules are irrelevant to the third-party
@c subproject, but they are required for the whole package to work.  It's
@c OK to have a rule that does nothing, so if you are integrating a
@c third-party project with no documentation or tag support, you could
@c simply augment its @file{Makefile} as follows:
@c 
通常,これらのルールの多くは,サードパーティーのサブプロジェクトには無
関係ですが,パッケージ全体がうまく動作するために要求されます.何もしな
いルールもOKなので,ドキュメントもタグのサポートもないサードパーティー
のプロジェクトを統合する場合は,単純に@file{Makefile}にを追加すること
も可能でしょう.

@example
EMPTY_AUTOMAKE_TARGETS = dvi pdf ps info html tags ctags
.PHONY: $(EMPTY_AUTOMAKE_TARGETS)
$(EMPTY_AUTOMAKE_TARGETS):
@end example

@c Another aspect of integrating third-party build systems is whether
@c they support VPATH builds.  Obviously if the subpackage does not
@c support VPATH builds the whole package will not support VPATH builds.
@c This in turns means that @code{make distcheck} will not work, because
@c it relies on VPATH builds.  Some people can live without this
@c (actually, many Automake users have never heard of @code{make
@c distcheck}).  Other people may prefer to revamp the existing
@c @file{Makefile}s to support VPATH.  Doing so does not necessarily
@c require Automake, only Autoconf is needed (@pxref{Build Directories, ,
@c Build Directories, autoconf, The Autoconf Manual}).  The necessary
@c substitutions: @code{@@scrdir@@}, @code{@@top_srcdir@@}, and
@c @code{@@top_buildir@@} are defined by @file{configure} when it
@c processes a @file{Makefile} (@pxref{Preset Output Variables, , Preset
@c Output Variables, autoconf, The Autoconf Manual}), they are not
@c computed by the Makefile like the aforementioned @code{$(distdir)} and
@c @code{$(top_distdir)} variables..
@c 
サードパーティーのビルドシステムとの統合のもう一つの側面は,それらが
VPATHのビルドをサポートしているかどうかによります.明らかに,サブパッ
ケージがVPATHのビルドをサポートしていない場合,パッケージ全体ではVPATH 
のビルドをサポートしないことになります.言い替えると,@code{make
distcheck}はVPATHのビルドに依存するため動作しないことを意味します.こ
れを利用しないことも可能です(実際,Automakeユーザには@code{make
distcheck}を聞いたこともない人がたくさんいます).それ以外の人々は,既
存の@file{Makefile}をVPATHをサポートするように改造するかもしれません.
そうすることの必要性をAutomakeが要求するわけではありませんが.Autoconf 
だけは必要とします(@pxref{Build Directories, , Build Directories,
autoconf, The Autoconf Manual}).必要となる代入は,@file{Makefile}の処
理で@file{configure}で定義される@code{@@scrdir@@},
@code{@@top_srcdir@@},そして@code{@@top_buildir@@}で(@pxref{Preset
Output Variables, , Preset Output Variables, autoconf, The Autoconf
Manual}),それらは前述の@code{$(distdir)}と@code{$(top_distdir)}変数の
ようにMakefileで計算されません.

@c It is sometimes inconvenient to modify a third-party @file{Makefile}
@c to introduce the above required targets.  For instance one may want to
@c keep the third-party sources untouched to ease upgrades to new
@c versions.
@c 
サードパーティーの@file{Makefile}が上記で要求されるターゲットを導入す
るように編集するのは,不便なことも時々あります.例えば,新しいバージョ
ンに簡単に更新できるようサードパーティのソースをいじらないようにしたい
人もいるかもしれません.

@cindex @file{GNUmakefile} including @file{Makefile}
@c Here are two other ideas.  If GNU make is assumed, one possibility is
@c to add to that subdirectory a @file{GNUmakefile} that defines the
@c required targets and include the third-party @file{Makefile}.  For
@c this to work in VPATH builds, @file{GNUmakefile} must lie in the build
@c directory; the easiest way to do this is to write a
@c @file{GNUmakefile.in} instead, and have it processed with
@c @code{AC_CONFIG_FILES} from the outer package.  For example if we
@c assume @file{Makefile} defines all targets except the documentation
@c targets, and that the @code{check} target is actually called
@c @code{test}, we could write @file{GNUmakefile} (or
@c @file{GNUmakefile.in}) like this:
@c 
他にも二つの考えがあります.GNU makeと仮定する場合,一つの方法として,
要求されるターゲットを追加しサードパーティの@file{Makefile}をインクルー
ドした@file{GNUmakefile}をサブディレクトリに追加することが可能です.
VPATHのビルドでこれを動作するため,@file{GNUmakefile}はディレクトリの
ビルドでだます必要があります.こうするための最も簡単な方法は,代わりに
これを@file{GNUmakefile.in}に書き,外部パッケージから
@code{AC_CONFIG_FILES}で処理させることです.例えば,@file{Makefile}で
ドキュメントのターゲット以外のすべてのターゲットを定義していると仮定し,
@code{check}ターゲットは実際には@code{test}で呼び出される場合,
@file{GNUmakefile}(または@file{GNUmakefile.in})を以下のように書くでしょ
う.

@example
# First, include the real Makefile
include Makefile
# Then, define the other targets needed by Automake Makefiles.
.PHONY: dvi pdf ps info html check
dvi pdf ps info html:
check: test
@end example

@cindex Proxy @file{Makefile} for third-party packages
@c A similar idea that does not use @code{include} is to write a proxy
@c @file{Makefile} that dispatches rules to the real @file{Makefile},
@c either with @code{$(MAKE) -f Makefile.real $(AM_MAKEFLAGS) target} (if
@c it's OK to rename the original @file{Makefile}) or with @code{cd
@c subdir && $(MAKE) $(AM_MAKEFLAGS) target} (if it's OK to store the
@c subdirectory project one directory deeper).  The good news is that
@c this proxy @file{Makefile} can be generated with Automake.  All we
@c need are -local targets (@pxref{Extending}) that perform the dispatch.
@c Of course the other Automake features are available, so you could
@c decide to let Automake perform distribution or installation.  Here is
@c a possible @file{Makefile.am}:
@c 
@code{include}を使用しない同じような考えは,本物の@file{Makefile}にルー
ルを送る,代わりの@file{Makefile}を書くことで,@code{$(MAKE) -f
Makefile.real $(AM_MAKEFLAGS) target} (オリジナルの@file{Makefile}の名
前を変更できる場合),または,@code{cd subdir && $(MAKE)
$(AM_MAKEFLAGS) target} (サブディレクトリのプロジェクトの階層をもう一
つ深くできる場合)のいずれかを用います.この代わりの@file{Makefile}を
Automakeで生成可能だというのは,良い知らせでしょう.ルールを送りつける 
-local ターゲット(@pxref{Extending})だけが必要です.もちろん,それ以外
のAutomakeの機能も利用可能なので,Automakeに配布とインストールを実行さ
せることを決定することも可能でしょう.以下は,実行可能な
@file{Makefile.am}です.

@example
all-local:
        cd subdir && $(MAKE) $(AM_MAKEFLAGS) all
check-local:
        cd subdir && $(MAKE) $(AM_MAKEFLAGS) test
clean-local:
        cd subdir && $(MAKE) $(AM_MAKEFLAGS) clean

# Assuming the package knows how to install itself
install-data-local:
        cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-data
install-exec-local:
        cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-exec
uninstall-local:
        cd subdir && $(MAKE) $(AM_MAKEFLAGS) uninstall

# Distribute files from here.
EXTRA_DIST = subdir/Makefile subdir/program.c ...
@end example

@c Pushing this idea to the extreme, it is also possible to ignore the
@c subproject build system and build everything from this proxy
@c @file{Makefile.am}.  This might sounds very sensible if you need VPATH
@c builds but the subproject does not support them.
@c 
このアイディアは最後の手段で,サブプロジェクトのビルドシステムを無視し,
すべてをこの代わりの@file{Makefile.am}で生成します.これは,VPATHのビ
ルドが必要でサブプロジェクトがそれをサポートしていない場合,非常に理に
かなったものに感じるでしょう.

@node Distributing
@c @chapter Distributing @file{Makefile.in}s
@chapter @file{Makefile.in}の配布

@c Automake places no restrictions on the distribution of the resulting
@c @file{Makefile.in}s.  We still encourage software authors to
@c distribute their work under terms like those of the GPL, but doing so
@c is not required to use Automake.
@c 
Automakeは,結果として生じる@file{Makefile.in}の配布に制限を置きません.
我々は,ソフトウェアの著者にGPLのような用語の下でその仕事を流通させる
ことを奨励しますが,そうすることはAutomakeを使用することにで要求されま
せん.

@c Some of the files that can be automatically installed via the
@c @code{--add-missing} switch do fall under the GPL@.  However, these also
@c have a special exception allowing you to distribute them with your
@c package, regardless of the licensing you choose.
@c 
@code{--add-missing}スイッチによって自動的にインストールすることが可能
なファイルにはGPLに従うものもあります.しかし,選択したライセンスを気
にせず,パッケージとともに配布することができるよう,これらにも特別な例
外があります.


@node API versioning
@c @chapter Automake API versioning
@chapter AutomakeのAPIのバージョン管理

@c New Automake releases usually include bug fixes and new features.
@c Unfortunately they may also introduce new bugs and incompatibilities.
@c This makes four reasons why a package may require a particular Automake
@c version.
@c 
通常,新しいAutomakeのリリースにはバグの修正と新しい機能が含まれていま
す.残念ながら,それらは新しいバグと非互換性ももたらす可能性があります.
このことは,パッケージがAutomakeの特定のバージョンを要求する可能性とな
る四つの理由になります.

@c Things get worse when maintaining a large tree of packages, each one
@c requiring a different version of Automake.  In the past, this meant that
@c any developer (and sometime users) had to install several versions of
@c Automake in different places, and switch @samp{$PATH} appropriately for
@c each package.
@c 
大きなツリーのパッケージを管理するとき,それぞれが異なるバージョンの
Automakeを要求することが問題になります.過去には,開発者(と時にはユー
ザが)異なるバージョンのAutomakeを異なる場所にインストールし,それぞれ
のパッケージに対して適切な@samp{$PATH}に切替える必要があったという意味
です.

@c Starting with version 1.6, Automake installs versioned binaries.  This
@c means you can install several versions of Automake in the same
@c @samp{$prefix}, and can select an arbitrary Automake version by running
@c @samp{automake-1.6} or @samp{automake-1.7} without juggling with
@c @samp{$PATH}.  Furthermore, @file{Makefile}'s generated by Automake 1.6
@c will use @samp{automake-1.6} explicitly in their rebuild rules.
@c 
バージョン1.6で開始していますが,Automakeはバージョン管理されたバイナ
リをインストールします.これは同じ@samp{$prefix}で複数のバージョンの
Automakeをインストールすることが可能で,@samp{$PATH}で誤魔化すこと無く
@samp{automake-1.6}や@samp{automake-1.7}を実行することで任意のバージョ
ンのAutomakeを選択することが可能だということを意味します.さらに,
Automake 1.6で生成された@file{Makefile}は,リビルドのルールで明示的に
@samp{automake-1.6}を使用します.

@c The number @samp{1.6} in @samp{automake-1.6} is Automake's API version,
@c not Automake's version.  If a bug fix release is made, for instance
@c Automake 1.6.1, the API version will remain 1.6.  This means that a
@c package which work with Automake 1.6 should also work with 1.6.1; after
@c all, this is what people expect from bug fix releases.
@c 
@samp{automake-1.6}の@samp{1.6}は,Automakeのバージョンではなく
AutomakeのAPIのバージョンです.バグの修正版が作成された場合,例えば
Automake 1.6.1になりますが,APIのバージョンは1.6のままです.これは,
Automake 1.6で動作するパッケージは1.6.1でも動作することを意味します.
結局,これは人々がバグの修正版に期待するものになります.

@c If your package relies on a feature or a bug fix introduced in
@c a release, you can pass this version as an option to Automake to ensure
@c older releases will not be used.  For instance, use this in your
@c @file{configure.ac}:
@c 
パッケージがリリースで導入された機能やバグの修正に依存している場合,古
いリリースを使用しないことを確実にするため,Automakeへのオプションとし
てこのバージョンを渡すことが可能です.例えば,@file{configure.ac}で以
下の内容を使用してください.

@example
  AM_INIT_AUTOMAKE(1.6.1)    dnl Require Automake 1.6.1 or better.
@end example
@noindent
@c or, in a particular @file{Makefile.am}:
@c 
または特定の@file{Makefile.am}で以下の内容を使用してください.

@example
  AUTOMAKE_OPTIONS = 1.6.1   # Require Automake 1.6.1 or better.
@end example
@noindent
@c Automake will print an error message if its version is
@c older than the requested version.
@c 
Automakeのバージョンが要求されたバージョンより古い場合,Automakeはエラー
メッセージを出力します.


@c @heading What is in the API
@heading APIの中身

@c Automake's programming interface is not easy to define.  Basically it
@c should include at least all @strong{documented} variables and targets
@c that a @samp{Makefile.am} author can use, any behavior associated with
@c them (e.g. the places where @samp{-hook}'s are run), the command line
@c interface of @samp{automake} and @samp{aclocal}, @dots{}
@c 
Automakeのプログラミングインターフェースは簡単に定義できません.基本的
に,全ての@strong{ドキュメント化されている}変数と@samp{Makefile.am}の
著者が利用可能なターゲットを少なくとも含めるべきで,動作はそれらに関連
していて(例えば,@samp{-hook}が実行される場所),@samp{automake}と
@samp{aclocal}のコマンドラインインターフェースがあって,@dots{}

@c @heading What is not in the API
@heading APIには無いもの

@c Every undocumented variable, target, or command line option, is not part
@c of the API@.  You should avoid using them, as they could change from one
@c version to the other (even in bug fix releases, if this helps to fix a
@c bug).
@c 
ドキュメント化されていない変数,ターゲット,またはコマンドラインオプショ
ンは全て,APIの一部ではありません.バージョンが変われば(バグの修正に役
立つ場合は,バグの修正版でも) 変更されるかもしれないので,それらを使用
することは避けるべきです.

@c If it turns out you need to use such a undocumented feature, contact
@c @email{automake@@gnu.org} and try to get it documented and exercised by
@c the test-suite.
@c 
そのようなドキュメント化されていない機能を使用する必要があると判明した
場合,@email{automake@@gnu.org}でコンタクトを取り,ドキュメントを書き
テストスイートで試してみてください.

@node Upgrading
@c @chapter Upgrading a Package to a Newer Automake Version
@chapter より新しいAutomakeのバージョンにパッケージを更新

@c Automake maintains three kind of files in a package.
@c 
Automakeは,パッケージの三種類のファイルを管理します.

@itemize
@c @item @file{aclocal.m4}
@c @item @file{Makefile.in}s
@c @item auxiliary tools like @file{install-sh} or @file{py-compile}
@c 
@item @file{aclocal.m4}
@item @file{Makefile.in}
@item @file{install-sh}や@file{py-compile}のような追加ツール
@end itemize

@c @file{aclocal.m4} is generated by @command{aclocal} and contains some
@c Automake-supplied M4 macros.  Auxiliary tools are installed by
@c @samp{automake --add-missing} when needed.  @file{Makefile.in}s are
@c built from @file{Makefile.am} by @command{automake}, and rely on the
@c definitions of the M4 macros put in @file{aclocal.m4} as well as the
@c behavior of the auxiliary tools installed.
@c 
@file{aclocal.m4}は@command{aclocal}で生成され,それにはAutomakeが提供
するM4マクロが含まれています.補助的なツールは,必要なときは
@samp{automake --add-missing}でインストールされます.
@file{Makefile.in}は,@command{automake}と,@file{aclocal.m4}に書かれ
ているM4マクロの定義,そして,インストールされた追加ツールの動作によっ
て,@file{Makefile.am}からビルドされます.

@c Because all these files are closely related, it is important to
@c regenerate all of them when upgrading to a newer Automake release.
@c The usual way to do that is
@c 
これらすべてのファイルは,密接に関わっているので,新しいAutomakeのリリー
スに更新したとき,それらすべてを再生成することが重要になります.通常は
以下のようにします.

@example
aclocal # with any option needed (such a -I m4)
autoconf
automake --add-missing --force-missing
@end example

@noindent
@c or more conveniently:
@c 
さらに便利な以下もあります.

@example
autoreconf -vfi
@end example

@c The use of @code{--force-missing} ensures that auxiliary tools will be
@c overridden by new versions (@pxref{Invoking Automake}).
@c 
@code{--force-missing}を使用することで,追加ツールは確実に新しいバージョ
ンに上書きされます(@pxref{Invoking Automake}).

@c It is important to regenerate all these files each time Automake is
@c upgraded, even between bug fixes releases.  For instance it is not
@c unusual for a bug fix to involve changes to both the rules generated
@c in @file{Makefile.in} and the supporting M4 macros copied to
@c @file{aclocal.m4}.
@c 
Automakeが更新されるたびに,バグフィックスのリリースであっても,これら
のファイルすべてを再生成することが重要です.例えば,バグフィクスで,
@file{Makefile.in}で生成されるルールと@file{aclocal.m4}にコピーされる
M4マクロのサポートの両方が必要になることもよくあることです.

@c Presently @command{automake} is able to diagnose situations where
@c @file{aclocal.m4} has been generated with another version of
@c @command{aclocal}.  However it never checks whether auxiliary scripts
@c are up-to-date.  In other words, @command{automake} will tell you when
@c @command{aclocal} needs to be rerun, but it will never diagnose a
@c missing @code{--force-missing}.
@c 
間もなく,@file{aclocal.m4}が別のバージョンの@command{aclocal}で生成さ
れた状況で,@command{automake}が状況診断することも可能になります.しか
し,追加のスクリプトが最新かどうかは決して調査しません.言い替えると,
@command{automake}は@command{aclocal}の再実行が必要だということを伝え
ますが,@code{--force-missing}が足りないことを決して診断しないというこ
とです.

@c Before upgrading to a new major release, it is a good idea to read the
@c file @file{NEWS}.  This file lists all changes between releases: new
@c features, obsolete constructs, known incompatibilities, and
@c workarounds.
@c 
新たなメジャーリリースに更新する前に,@file{NEWS}ファイルを読むのは良
い考えです.このファイルには,リリース間のすべての変更点がリストアップ
されています.それらは,新しい機能,時代遅れの構成物,既知の非互換性,
そしてその回避方法です.

@node FAQ
@c @chapter Frequently Asked Questions about Automake
@chapter Automakeに関するよくある質問と答え

@c This chapter covers some questions that often come up on the mailing
@c lists.
@c 
この章では,メーリングリストによく上がる質問をカバーします.

@menu
* CVS::                         CVS and generated files
* maintainer-mode::             missing and AM_MAINTAINER_MODE
* wildcards::                   Why doesn't Automake support wildcards?
* distcleancheck::              Files left in build directory after distclean
* renamed objects::             Why are object files sometimes renamed?
* Multiple Outputs::            Writing rules for tools with many output files
@end menu

@node CVS
@c @section CVS and generated files
@section CVSと生成されるファイル

@c @subsection Background: distributed generated files
@subsection 背景:生成されるファイルの配布
@cindex generated files, distributed
@cindex rebuild rules

@c Packages made with Autoconf and Automake ship with some generated
@c files like @file{configure} or @file{Makefile.in}.  These files were
@c generated on the developer's host and are distributed so that
@c end-users do not have to install the maintainer tools required to
@c rebuild them.  Other generated files like Lex scanners, Yacc parsers,
@c or Info documentation, are usually distributed on similar grounds.
@c 
AutoconfとAutomakeを用いて作成したパッケージは,@file{configure}や
@file{Makefile.in}といった生成されるファイルとともに配布されます.これ
らのファイルは開発者のホストで生成され,それらをビルドするためにエンド
ユーザが管理用のツールをインストールする必要が無いように配布されます.
Lexスキャナー,Yaccパーサ,またInfoドキュメントのような,それ以外に生
成されるファイルは,同じ理由で通常配布されます.

@c Automake outputs rules in @file{Makefile}s to rebuild these files.  For
@c instance @command{make} will run @command{autoconf} to rebuild
@c @file{configure} whenever @file{configure.ac} is changed.  This makes
@c development safer by ensuring a @file{configure} is never out-of-date
@c with respect to @file{configure.ac}.
@c 
例えば,@file{configure.ac}が変更されたときは@file{configure}をリビル
ドするために@command{autoconf}を実行します.@file{configure}が対応する
@file{configure.ac}より古くないように,開発者が確実に行なえます.

@c As generated files shipped in packages are up-to-date, and because
@c @command{tar} preserves times-tamps, these rebuild rules are not
@c triggered when a user unpacks and builds a package.
@c 
パッケージで配布されている,生成されたファイルは最新で,@command{tar} 
でタイムスタンプを保存しているので,これらのリビルドのルールはユーザが
パッケージを展開しビルドするときも開始されません.

@c @subsection Background: CVS and timestamps
@subsection 背景:CVSとタイムスタンプ
@cindex timestamps and CVS
@cindex CVS and timestamps

@c Unless you use CVS keywords (in which case files must be updated at
@c commit time), CVS preserves timestamp during @code{cvs commit} and
@c @code{cvs import -d} operations.
@c 
CVSキーワードを使用していない限り(この状況ではコミット時にファイルを更
新する必要があります),@code{cvs commit}と@code{cvs import -d}の処理中
にCVSが保持しているタイムスタンプは保持されます.

@c When you check out a file using @code{cvs checkout} its timestamp is
@c set to that of the revision which is being checked out.
@c 
@code{cvs checkout}を使用してファイルをチェックアウトしたとき,そのタ
イムスタンプは,チェックアウトしたリビジョンで設定されたタイムスタンプ
になります.

@c However, during @command{cvs update}, files will have the date of the
@c update, not the original timestamp of this revision.  This is meant to
@c make sure that @command{make} notices sources files have been updated.
@c 
しかし,@command{cvs update}したとき,ファイルの日付が更新されますが,
オリジナルのタイムスタンプはこのリビジョンになります.これは,
@command{make}でソースファイルが更新されたことに確実に気付くことを意味
します.

@c This times tamp shift is troublesome when both sources and generated
@c files are kept under CVS.  Because CVS processes files in alphabetical
@c order, @file{configure.ac} will appear older than @file{configure}
@c after a @command{cvs update} that updates both files, even if
@c @file{configure} was newer than @file{configure.ac} when it was
@c checked in.  Calling @code{make} will then trigger a spurious rebuild
@c of @file{configure}.
@c 
このタイムスタンプの変更は,ソースと生成されたファイルの両方をCVSに保
持しているときは面倒です.CVSはアルファベット順にファイルを処理するの
で,@command{cvs update}で両方のファイルを更新した後は,チェックイン時
に@file{configure.ac}より@file{configure}のほうが新しい場合でも,
@file{configure}より@file{configure.ac}が古いものとして表されます.
@code{make}を呼び出すと,間違って@file{configure}のリビルドが開始され
ます.

@c @subsection Living with CVS in Autoconfiscated projects
@subsection Autoconfを利用したプロジェクトにおけるCVSとの共存
@cindex CVS and generated files
@cindex generated files and CVS

@c There are basically two clans amongst maintainers: those who keep all
@c distributed files under CVS, including generated files, and those who
@c keep generated files @emph{out} of CVS.
@c 
基本的に二種類の管理者がいます.生成されるファイルを含め,すべての配布
されるファイルをCVSの元に保持している人,そして,生成されたファイルを
CVSの@emph{外部に}保持している人です.

@c @subsubheading All files in CVS
@subsubheading すべてのファイルをCVSに入れる

@itemize @bullet
@item
@c The CVS repository contains all distributed files so you know exactly
@c what is distributed, and you can checkout any prior version entirely.
@c 
CVSリポジトリはすべての配布されるファイルを含んでいるので,配布される
ものが何かを正確に知っていて,前のバージョン全体をチェックアウトするこ
とも可能です.

@item
@c Maintainers can see how generated files evolve (for instance you can
@c see what happens to your @file{Makefile.in}s when you upgrade Automake
@c and make sure they look OK).
@c 
管理者は,生成されるファイルを展開する方法を知ることが可能です(例えば,
Automakeを更新したとき,@file{Makefile.in}で生じたことを知り,大丈夫で
あることを確認することが可能です).

@item
@c Users do not need the autotools to build a checkout of the project, it
@c works just like a released tarball.
@c 
チェックアウトしたプロジェクトをビルドするために,ユーザはautotoolが不
要で,リリースされたtarballと同様に動作します.

@item
@c If users use @command{cvs update} to update their copy, instead of
@c @command{cvs checkout} to fetch a fresh one, timestamps will be
@c inaccurate.  Some rebuild rules will be triggered and attempt to
@c run developer tools such as @command{autoconf} or @command{automake}.
@c 
ユーザが,新しいものを取得するために@command{cvs checkout}する代わりに,
コピーを更新するために@command{cvs update}を使用する場合,タイムスタン
プは不正確になります.@command{autoconf}や@command{automake}のような管
理者用のツールを,実行を開始したり試みたりするリビルドルールもあります.

@c Actually, calls to such tools are all wrapped into a call to the
@c @command{missing} script discussed later (@pxref{maintainer-mode}).
@c @command{missing} will take care of fixing the timestamps when these
@c tools are not installed, so that the build can continue.
@c 
実際,そのようなツールの呼び出しは,後で議論する@command{missing}スク
リプトで呼び出しにすべてラップされています(@pxref{maintainer-mode}).
@command{missing}は,これらのツールがインストールされていないとき,ビ
ルドが続けられるように,タイムスタンプを修正します.

@item
@c In distributed development, developers are likely to have different
@c version of the maintainer tools installed.  In this case rebuilds
@c triggered by timestamp lossage will lead to spurious changes
@c to generated files.  There are several solutions to this:
@c 
配布されている開発物では,開発者はバージョンが異なる管理ツールをインス
トールしていることもよくあります.この状況では,失われたタイムスタンプ
によるリビルドの開始が,生成されるファイルを間違って変更します.この問
題の解決方法はいくつかあります.

@itemize
@item
@c All developers should use the same versions, so that the rebuilt files
@c are identical to files in CVS.  (This starts to be difficult when each
@c project you work on uses different versions.)
@c 
リビルドされるファイルがCVSのファイルと同じになるように,すべての開発
者が同じバージョンを使用する.(作業しているプロジェクトが異なるバージョ
ンを使用しているとき,こうすることは難しくなります.)
@item
@c Or people use a script to fix the timestamp after a checkout (the GCC
@c folks have such a script).
@c 
または,チェックアウト後にタイムスタンプを修正するスクリプトを使用する
(GCCの人々は,そのようなスクリプトを所有しています).
@item
@c Or @file{configure.ac} uses @code{AM_MAINTAINER_MODE}, which will
@c disable all these rebuild rules by default.  This is further discussed
@c in @ref{maintainer-mode}.
@c 
または,これらのリビルドルールすべてをデフォルトで利用不可能にするよう
に,@file{configure.ac}で@code{AM_MAINTAINER_MODE}を使用します.これは,
@ref{maintainer-mode}で更に議論していきます.
@end itemize

@item
@c Although we focused on spurious rebuilds, the converse can also
@c happen.  CVS's timestamp handling can also let you think an
@c out-of-date file is up-to-date.
@c 
我々は間違ったリビルドに注目していますが,反対のことも生じます.CVSの
タイムスタンプの処理で,古いと思われるファイルが最新のものになってしま
うこともあるはずです.

@c For instance, suppose a developer has modified @file{Makefile.am} and
@c rebuilt @file{Makefile.in}, and then decide to do a last-minute change
@c to @file{Makefile.am} right before checking in both files (without
@c rebuilding @file{Makefile.in} to account for the change).
@c 
例えば,開発者が編集された@file{Makefile.am}とリビルドされた
@file{Makefile.in}を所有していて,両方のファイルを調査する直前に
@file{Makefile.am}の変更を決定したと仮定します(変更に対応する
@file{Makefile.in}をリビルドする前です).

@c This last change to @file{Makefile.am} make the copy of
@c @file{Makefile.in} out-of-date.  Since CVS processes files
@c alphabetically, when another developer @code{cvs update} his or her
@c tree, @file{Makefile.in} will happen to be newer than
@c @file{Makefile.am}.  This other developer will not see
@c @file{Makefile.in} is out-of-date.
@c 
この最後の@file{Makefile.am}の変更で,@file{Makefile.in}のコピーは古い
ものになっています.CVSはファイルをアルファベット順に処理するので,他
の開発者がツリー上で@code{cvs update}するとき,@file{Makefile.in}が
@file{Makefile.am}より新しくなってしまいます.この開発者は,
@file{Makefile.in}が古いことが分からないでしょう.

@end itemize

@c @subsubheading Generated files out of CVS
@subsubheading 生成されるファイルをCVSに入れない

@c One way to get CVS and @code{make} working peacefully is to never
@c store generated files in CVS, i.e., do not CVS-control files which
@c are @code{Makefile} targets (also called @emph{derived} files).
@c 
CVSと@code{make}を平和に動作させる一つの方法は,生成されるファイルを
CVSに保存しないことで,すなわち,@code{Makefile}のターゲット(@emph{派
生}ファイルとも呼ばれます)をCVSの制御下におかないことです.

@c This way developers are not annoyed by changes to generated files.  It
@c does not matter if they all have different versions (assuming they are
@c compatible, of course).  And finally, timestamps are not lost, changes
@c to sources files can't be missed as in the
@c @file{Makefile.am}/@file{Makefile.in} example discussed earlier.
@c 
この方法では,開発者は生成されるファイルの変更で悩むことはありません.
全員が異なるバージョンを所有している場合は問題になります(もちろん互換
性があると仮定してもです).結局,タイムスタンプは失われ,ソースファイ
ルへの変更は,これまでに議論してきた
@file{Makefile.am}/@file{Makefile.in}の例のように失われてしまうはずで
す.

@c The drawback is that the CVS repository is not an exact copy of what
@c is distributed and that users now need to install various development
@c tools (maybe even specific versions) before they can build a checkout.
@c But, after all, CVS's job is versioning, not distribution.
@c 
欠点は,配布されるものの正確なコピーがCVSリポジトリに無いことと,チェッ
クアウトしたものをビルド可能にする前に,様々な開発ツール(バージョンが
指定されるかもしれません)をユーザがインストールする必要があるというこ
とです.しかし,結局は,CVSの仕事はバージョン管理であり,配布ではあり
ません.

@c Allowing developers to use different versions of their tools can also
@c hide bugs during distributed development.  Indeed, developers will be
@c using (hence testing) their own generated files, instead of the
@c generated files that will be released actually.  The developer who
@c prepares the tarball might be using a version of the tool that
@c produces bogus output (for instance a non-portable C file), something
@c other developers could have noticed if they weren't using their own
@c versions of this tool.
@c 
開発者が異なるバージョンのツールの使用を可能にすると,配布された開発物
のバグを隠すことにもなります.事実,開発者は,実際のリリースで生成され
るファイルの代わりに,(テストであっても)自分が生成したファイルを使用し
ます.tarballを準備している開発者は,使用しているツールのバージョンが
間違った出力を生成するものを使用している可能性があり(例えば,移植性の
ないCファイル),他の開発者が,独自のバージョンのこのツールを使用してい
ない場合,注意されることになるでしょう.

@c @subsection Third-party files
@subsection サードパーティーのファイル
@cindex CVS and third-party files
@cindex third-party files and CVS

@c Another class of files not discussed here (because they do not cause
@c timestamp issues) are files which are shipped with a package, but
@c maintained elsewhere.  For instance tools like @command{gettextize}
@c and @command{autopoint} (from Gettext) or @command{libtoolize} (from
@c Libtool), will install or update files in your package.
@c 
(タイムスタンプの問題が無いので)ここでは議論しませんが,それ以外に分類
されるファイルとして,パッケージとともに配布されるけれども,どこでも管
理されていないファイルがあります.例えば,@command{gettextize}と
@command{autopoint}(Gettext由来)や,@command{libtoolize}(Libtool由来) 
のようなツールは,パッケージにファイルをインストールしたり更新したりし
ます.

@c These files, whether they are kept under CVS or not, raise similar
@c concerns about version mismatch between developers' tools.  The
@c Gettext manual has a section about this, see @ref{CVS Issues, CVS
@c Issues, Integrating with CVS, gettext, GNU gettext tools}.
@c 
これらのファイルは,CVSに保持しようが保持しまいが,開発者のツール間の
バージョンの違いについて,似たようなことが生じます.Gettextのマニュア
ルにはこれに関するセクションがあります.@ref{CVS Issues, CVS Issues,
Integrating with CVS, gettext, GNU gettext tools}を参照して下さい.

@node maintainer-mode
@c @section @command{missing} and @code{AM_MAINTAINER_MODE}
@section @command{missing}と@code{AM_MAINTAINER_MODE}

@subsection @command{missing}
@cindex missing, purpose

@c The @command{missing} script is a wrapper around several maintainer
@c tools, designed to warn users if a maintainer tool is required but
@c missing.  Typical maintainer tools are @command{autoconf},
@c @command{automake}, @command{bison}, etc.  Because file generated by
@c these tools are shipped with the other sources of a package, these
@c tools shouldn't be required during a user build and they are not
@c checked for in @file{configure}.
@c 
@command{missing}スクリプトは,いくつかの管理用ツールのラッパーで,要
求される管理用ツールを持っていないユーザのために設計されています.通常,
管理用ツールとは,@command{autoconf},@command{automake},
@command{bison}等です.これらのツールで生成されるファイルは,パッケー
ジのその他のファイルとともに配布されるので,ユーザがビルドしたり,それ
らがconfigureで調査されている間は,これらのツールは要求されません.

@c However, if for some reason a rebuild rule is triggered and involves a
@c missing tool, @command{missing} will notice it and warn the user.
@c Besides the warning, when a tool is missing, @command{missing} will
@c attempt to fix timestamps in a way which allow the build to continue.
@c For instance @command{missing} will touch @file{configure} if
@c @command{autoconf} is not installed.  When all distributed files are
@c kept under CVS, this feature of @command{missing} allows user
@c @emph{with no maintainer tools} to build a package off CVS, bypassing
@c any timestamp inconsistency implied by @code{cvs update}.
@c 
しかし,理由があってリビルドのルールが開始され,足りないツールが呼び出
される場合,@command{missing}はユーザに警告します.ツールが無いとき,
警告はされますが,ビルドの継続を可能にする方向で,@command{missing}は
タイムスタンプを修正を試みます.例えば,@command{autoconf}がインストー
ルされていない場合,@command{missing}は@file{configure}を
@command{touch}します.配布されるすべてのファイルがCVSに保持されている
場合,@command{missing}のこの機能で,ユーザは@emph{管理用ツールが無く
ても,}@code{cvs update}で暗黙に指定されたタイムスタンプを回避して,
CVSからのパッケージをビルドすることが可能になります.

@c If the required tool is installed, @command{missing} will run it and
@c won't attempt to continue after failures.  This is correct during
@c development: developers love fixing failures.  However, users with
@c wrong versions of maintainer tools may get an error when the rebuild
@c rule is spuriously triggered, halting the build.  This failure to let
@c the build continue is one of the arguments of the
@c @code{AM_MAINTAINER_MODE} advocates.
@c 
要求されるツールがインストールされている場合,@command{missing}はそれ
を実行し,異常終了した後は継続しようとしません.これは開発時には正しい
もので,開発者は異常終了を修正したいものです.しかし,管理用ツールの違
うバージョンを持っているユーザは,リビルドルールが間違って開始されると
き,ビルドが終了しエラーになるかもしれません.ビルドの継続による異常終
了は,@code{AM_MAINTAINER_MODE}で主張している論点の一つです.

@subsection @code{AM_MAINTAINER_MODE}
@cindex AM_MAINTAINER_MODE, purpose
@cvindex AM_MAINTAINER_MODE

@c @code{AM_MAINTAINER_MODE} disables the so called "rebuild rules" by
@c default.  If you have @code{AM_MAINTAINER_MODE} in
@c @file{configure.ac}, and run @code{./configure && make}, then
@c @command{make} will *never* attempt to rebuilt @file{configure},
@c @file{Makefile.in}s, Lex or Yacc outputs, etc.  I.e., this disables
@c build rules for files which are usually distributed and that users
@c should normally not have to update.
@c 
@code{AM_MAINTAINER_MODE}は,"リビルドのルール"の呼び出しをデフォルト
で利用不可能にします.@file{configure.ac}に@code{AM_MAINTAINER_MODE}が
あって,@code{./configure && make}を実行する場合,@command{make}は
@file{configure},@file{Makefile.in},LexやYaccの出力などのリビルドを* 
決して*試みません.すなわち,一般的に配布されるが,通常ユーザが更新す
る必要が無いファイルに対するビルドルールを利用不可能にします.

@c If you run @code{./configure --enable-maintainer-mode}, then these
@c rebuild rules will be active.
@c 
@code{./configure --enable-maintainer-mode}を実行する場合,これらのリ
ビルドルールが利用されるようになります.

@c People use @code{AM_MAINTAINER_MODE} either because they do want their
@c users (or themselves) annoyed by timestamps lossage (@pxref{CVS}), or
@c because they simply can't stand the rebuild rules and prefer running
@c maintainer tools explicitly.
@c 
ユーザ(や自分自身が)が失われたタイムスタンプ(@pxref{CVS})でうんざりし
たくないからとか,単純に,リビルドルールを使わないようにして管理用ツー
ルを明示的に実行したいから,といった理由で@code{AM_MAINTAINER_MODE}を
使用します.

@c @code{AM_MAINTAINER_MODE} also allows you to disable some custom build
@c rules conditionally.  Some developers use this feature to disable
@c rules that need exotic tools that users may not have available.
@c 
@code{AM_MAINTAINER_MODE}では,条件的なカスタムビルドのルールも利用不
可能にすることが可能になります.ユーザが利用不可能なおそれのある外部ツー
ルのルールを利用不可能にするため,この機能を使用する管理者もいます.

@c Several years ago Fran@,{c}ois Pinard pointed out several arguments
@c against @code{AM_MAINTAINER_MODE}.  Most of them relate to insecurity.
@c By removing dependencies you get non-dependable builds: change to
@c sources files can have no effect on generated files and this can be
@c very confusing when unnoticed.  He adds that security shouldn't be
@c reserved to maintainers (what @code{--enable-maintainer-mode}
@c suggests), on the contrary.  If one user has to modify a
@c @file{Makefile.am}, then either @file{Makefile.in} should be updated
@c or a warning should be output (this is what Automake uses
@c @code{missing} for) but the last thing you want is that nothing
@c happens and the user doesn't notice it (this is what happens when
@c rebuild rules are disabled by @code{AM_MAINTAINER_MODE}).
@c 
数年前,Fran@,{c}ois Pinardは@code{AM_MAINTAINER_MODE}にいくつかの引数
を付けるよう指示しました.それらのほとんどは不安定になり得ます.依存性
を削除することで,非依存のビルドにすることができます.ソースファイルを
変更することで,生成されるファイルに影響がなくなり,このことで,注意さ
れないときでも非常に混乱するはずです.彼は,安定は管理者に限定すべきで
はなく(@code{--enable-maintainer-mode}で提案されたもの),反対だと付け
加えました.ユーザが@file{Makefile.am}を編集すると,@file{Makefile.in} 
を更新する,または警告を出力すべきですが(これがAutomakeで
@code{missing}を使用する理由です),最終的に望むことは,何も起こらず,
ユーザは注意もされないことです(これは,@code{AM_MAINTAINER_MODE}でリビ
ルドのルールを利用不可能にすることです).

@c Jim Meyering, the inventor of the @code{AM_MAINTAINER_MODE} macro was
@c swayed by Fran@,{c}ois's arguments, and got rid of
@c @code{AM_MAINTAINER_MODE} in all of his packages.
@c 
@code{AM_MAINTAINER_MODE}マクロを開発したJim Meyeringは,Fran@,{c}ois 
との議論に動揺し,パッケージから@code{AM_MAINTAINER_MODE}を取り除きま
した.

@c Still many people continue to use @code{AM_MAINTAINER_MODE}, because
@c it helps them working on projects where all files are kept under CVS,
@c and because @command{missing} isn't enough if you have the wrong
@c version of the tools.
@c 
すべてのファイルをCVSに保持しているプロジェクトで作業する手助けとなり,
違うバージョンのツールを所有している場合は@command{missing}が十分では
ないので,今でも,@code{AM_MAINTAINER_MODE}を使用し続けている人はたく
さんいます.


@node wildcards
@c @section Why doesn't Automake support wildcards?
@section なぜAutomakeはワイルドカードをサポートしないのですか?
@cindex wildcards

@c Developers are lazy.  They often would like to use wildcards in
@c @file{Makefile.am}s, so they don't need to remember they have to
@c update @file{Makefile.am}s every time they add, delete, or rename a
@c file.
@c 
開発者は怠けものです.ファイルの追加,削除,または名前の変更のたびに,
@file{Makefile.am}の更新を忘れないようにする必要がないよう,
@file{Makefile.am}でワイルドカードを使用したいときもよくあります.

@c There are several objections to this:
@c 
これにはいくつかの欠点があります.
@itemize
@item
@c When using CVS (or similar) developers need to remember they have to
@c run @code{cvs add} or @code{cvs rm} anyway.  Updating
@c @file{Makefile.am} accordingly quickly becomes a reflex.
@c 
CVS(やそれに似たもの)を使用している管理者は,@code{cvs add}や@code{cvs
rm}を実行する必要があることを,とにかく覚えておく必要があります.とい
うわけで,@file{Makefile.am}も反射的にすぐ行なうようになります.

@c Conversely, if your application doesn't compile
@c because you forgot to add a file in @file{Makefile.am}, it will help
@c you remember to @code{cvs add} it.
@c 
逆に,アプリケーションが完全ではない場合,@file{Makefile.am}にファイル
を追加する必要があるので,それを@code{cvs add}することを覚えておく手助
けになります.

@item
@c Using wildcards makes easy to distribute files by mistake.  For
@c instance some code a developer is experimenting with (a test case,
@c say) but which should not be part of the distribution.
@c 
ワイルドカードを使用することで,間違ってファイルを配布しやすくなります.
例えば,開発者が(いわゆるテストケースで)調査するためのコードで,それは
配布物の一部にすべきではありません.

@item
@c Using wildcards it's easy to omit some files by mistake.  For
@c instance one developer creates a new file, uses it at many places,
@c but forget to commit it.  Another developer then checkout the
@c incomplete project and is able to run `make dist' successfully,
@c even though a file is missing.
@c 
ワイルドカードを使用すると,間違ってファイルを削除しやすくなります.例
えば,ある開発者が新しいファイルを作成し,それをたくさんの場所で使用し
ているが,これをコミットするのを忘れているとします.他の開発者は,不完
全なプロジェクトをチェックアウトしても,ファイルが足りなくても,問題無
く@samp{make dist}を実行することが可能です.

@item
@c Listing files, you control *exactly* what you distribute.
@c If some file that should be distributed is missing from your
@c tree, @code{make dist} will complain.  Besides, you don't distribute
@c more than what you listed.
@c 
ファイルをリストアップすると,配布するものを@emph{正確に}制御できます.
配布されるべきファイルがツリーに無い場合,@code{make dist}で文句を言わ
れます.さらに,リストアップしている以上のファイルを配布することもあり
ません.

@item
@c Finally it's really hard to @file{forget} adding a file to
@c @file{Makefile.am}, because if you don't add it, it doesn't get
@c compiled nor installed, so you can't even test it.
@c 
おしまいに,ファイルを@file{Makefile.am}に追加し忘れることは滅多に無く,
それは,追加していない場合,コンパイルもインストールもされず,テストす
らできないでしょう.
@end itemize

@c Still, these are philosophical objections, and as such you may disagree,
@c or find enough value in wildcards to dismiss all of them.  Before you
@c start writing a patch against Automake to teach it about wildcards,
@c let's see the main technical issue: portability.
@c 
それらすべてを却下するほとワイルドカードに十分な価値があるという反対意
見があるかもしれませんが,まだ哲学的な欠点もあります.Automakeにワイル
ドカードを伝えるためのパッチを書き始める前に,主な技術的な問題を見てい
きましょう.それは移植性です.

@c Although @code{$(wildcard ...)} works with GNU @command{make}, it is
@c not portable to other @command{make} implementations.
@c 
@code{$(wildcard ...)}はGNU @command{make}で動作しますが,他の
@command{make}の実装では移植性がありません.

@c The only way Automake could support @command{$(wildcard ...)} is by
@c expending @command{$(wildcard ...)} when @command{automake} is run.
@c Resulting @file{Makefile.in}s would be portable since they would
@c list all files and not use @code{$(wildcard ...)}.  However that
@c means developers need to remember they must run @code{automake} each
@c time they add, delete, or rename files.
@c 
Automakeで@command{$(wildcard ...)}をサポートする唯一の方法は,
@command{automake}の実行時に@command{$(wildcard ...)}を展開することで
す.結果として得られる@file{Makefile.in}には,@code{$(wildcard ...)}が
使用されておらず,すべてのファイルをリストアップしているので移植性があ
ります.しかしそれは,ファイルを追加,削除,または名前の変更をするたび
に,開発者が@code{automake}を実行する必要があるということを意味します.

@c Compared to editing @file{Makefile.am}, this is really little win.  Sure,
@c it's easier and faster to type @code{automake; make} than to type
@c @code{emacs Makefile.am; make}.  But nobody bothered enough to write a
@c patch add support for this syntax.  Some people use scripts to
@c generated file lists in @file{Makefile.am} or in separate
@c @file{Makefile} fragments.
@c 
@file{Makefile.am}を編集するより,実際は若干勝っています.確かに,
@code{emacs Makefile.am; make}と入力するより@code{automake; make}と入
力する方が簡単で速いでしょう.しかし,この構文のサポートを追加するのに
十分なパッチを書くことを邪魔する人はいません.@file{Makefile.am}や個別
の@file{Makefile}の断片にファイルリストを生成するスクリプトを使う人も
います.

@c Even if you don't care about portability, and are tempted to use
@c @code{$(wildcard ...)} anyway because you target only GNU Make, you
@c should know there are many places where Automake need to know exactly
@c which files should be processed.  As Automake doesn't know how to
@c expand @code{$(wildcard ...)}, you cannot use it in these places.
@c @code{$(wildcard ...)} is a black box comparable to @code{AC_SUBST}ed
@c variables as far Automake is concerned.
@c 
移植性に気を付けていなくても,GNU Makeだけをターゲットにしていて,なん
とかして@code{$(wildcard ...)}を使用したい場合でも,処理されるファイル
をAutomakeが正確に知っている必要がある場所がたくさんあることを知ってお
くべきです.Automakeは@code{$(wildcard ...)}を展開する方法を知らないの
で,これらの場所で使用することは不可能です.@code{$(wildcard ...)}は,
Automakeが尊重する@code{AC_SUBST}されている変数と比べてブラックボック
スになります.

@c You can get warnings about @code{$(wildcard ...}) constructs using the
@c @code{-Wportability} flag.
@c 
@code{-Wportability}フラグを使用すると,@code{$(wildcard ...)}の構成物
は警告されるはずです.

@node distcleancheck
@c @section Files left in build directory after distclean
@section distclean後にビルドディレクトリに残っているファイル
@cindex distclean, diagnostic
@cindex dependencies and distributed files
@trindex distclean
@trindex distcleancheck

@c This is a diagnostic you might encounter while running @code{make
@c distcheck}.
@c 
これは(Files left in build directory after distclean),@code{make
distcheck}時に遭遇する可能性がある診断結果です.

@c As explained in @ref{Dist}, @code{make distcheck} attempts to build
@c and check your package for errors like this one.
@c 
@ref{Dist}で説明したように,@code{make distcheck}では,このようなエラー
に対し,パッケージのビルドと調査を試みます.

@c @code{make distcheck} will perform a @code{VPATH} build of your
@c package, and then call @code{make distclean}.  Files left in the build
@c directory after @code{make distclean} has run are listed after this
@c error.
@c 
@code{make distcheck}は,パッケージの@code{VPATH}のビルドを実行し,
@code{make distclean}を呼び出します.@code{make distclean}が実行された
後で,ビルドディレクトリに残っているファイルは,このエラーの後でリスト
アップされます.

@c This diagnostic really covers two kinds of errors:
@c 
この診断結果は,実際には二種類のエラーをカバーしています.

@itemize @bullet
@item
@c files that are forgotten by distclean;
@c 
distcleanで忘れられているファイル.
@item
@c distributed files that are erroneously rebuilt.
@c 
間違ってリビルドされる配布ファイル.
@end itemize

@c The former left-over files are not distributed, so the fix is to mark
@c them for cleaning (@pxref{Clean}), this is obvious and doesn't deserve
@c more explanations.
@c 
残っている前者のファイルは配布されないので,クリーンするよう
(@pxref{Clean})印が付いているものを修正します.これは明白で,文句を言
われても仕方がありません.

@c The latter bug is not always easy to understand and fix, so let's
@c proceed with an example.  Suppose our package contains a program for
@c which we want to build a man page using @command{help2man}.  GNU
@c @command{help2man} produces simple manual pages from the @code{--help}
@c and @code{--version} output of other commands (@pxref{Top, , Overview,
@c help2man, The Help2man Manual}).  Because we don't to force want our
@c users to install @command{help2man}, we decide to distribute the
@c generated man page using the following setup.
@c 
後者のバグは,理解し修正するのが常に容易だというわけではないので,例を
用いて説明します.パッケージに@command{help2man}を使用してmanページを
ビルドしたいプログラムが含まれていると仮定します.GNU
@command{help2man}は,コマンドの@code{--help}と@code{--version}の出力
から簡単なマニュアルページを生成します(@pxref{Top, , Overview,
help2man, The Help2man Manual}).@command{help2man}のインストールをユー
ザに強制したくないので,以下のような設定を使用して生成されたmanページ
を配布するように決めました.

@example
# This Makefile.am is bogus.
bin_PROGRAMS = foo
foo_SOURCES = foo.c
dist_man_MANS = foo.1

foo.1: foo$(EXEEXT)
	help2man --output=foo.1 ./foo$(EXEEXT)
@end example

@c This will effectively distribute the man page.  However,
@c @code{make distcheck} will fail with:
@c 
これで,manページを効果的に配布します.しかし,@code{make distcheck}は
以下のように異常終了するでしょう.

@example
ERROR: files left in build directory after distclean:
./foo.1
@end example

@c Why was @file{foo.1} rebuilt?  Because although distributed,
@c @file{foo.1} depends on a non-distributed built file:
@c @file{foo$(EXEEXT)}.  @file{foo$(EXEEXT)} is built by the user, so it
@c will always appear to be newer than the distributed @file{foo.1}.
@c 
なぜ@file{foo.1}がリビルドされたのでしょうか?その理由は,配布はされな
いものの,@file{foo.1}は配布されないファイル@file{foo$(EXEEXT)}に依存
しているためです.@file{foo$(EXEEXT)}はユーザがビルドするので,それは
配布されている@file{foo.1}より常に新しいものになります.

@c @code{make distcheck} caught an inconsistency in our package.  Our
@c intent was to distribute @file{foo.1} so users do not need installing
@c @command{help2man}, however since this our rule causes this file to be
@c always rebuilt, users @emph{do} need @command{help2man}.  Either we
@c should ensure that @file{foo.1} is not rebuilt by users, or there is
@c no point in distributing @file{foo.1}.
@c 
@code{make distcheck}はパッケージ内の矛盾をとらえます.ユーザが
@command{help2man}をインストールする必要が無いように,@file{foo.1}を配
布するのが目的でしたが,このルールで今ではファイルが常にリビルドされ,
ユーザは@emph{どうしても}@command{help2man}が必要になります.
@file{foo.1}がユーザにリビルドされないことを確実にする,または
@file{foo.1}の配布を諦めるかのいずれかにすべきです.

@c More generally, the rule is that distributed files should never depend
@c on non-distributed built files.  If you distribute something
@c generated, distribute its sources.
@c 
より一般的には,配布されるファイルのルールには,配布されないビルドされ
るファイルに決して依存しないようにすべきです.生成されたものを配布する
場合,そのソースを配布してください.

@c One way to fix the above example, while still distributing
@c @file{foo.1} is to not depend on @file{foo$(EXEEXT)}.  For instance,
@c assuming @command{foo --version} and @command{foo --help} do not
@c change unless @file{foo.c} or @file{configure.ac} change, we could
@c write the following @file{Makefile.am}:
@c 
上記の例を修正する一つの方法として,配布される@file{foo.1}が
@file{foo$(EXEEXT)}に依存しないようにします.例えば,@command{foo
--version}と@command{foo --help}が,@file{foo.c}や@file{configure.ac} 
が変更されない限り変更されない状況では,以下のような@file{Makefile.am} 
を書くことが可能です.

@example
bin_PROGRAMS = foo
foo_SOURCES = foo.c
dist_man_MANS = foo.1

foo.1: foo.c $(top_srcdir)/configure.ac
        $(MAKE) $(AM_MAKEFLAGS) foo$(EXEEXT)
	help2man --output=foo.1 ./foo$(EXEEXT)
@end example

@c This way, @file{foo.1} will not get rebuilt every time
@c @file{foo$(EXEEXT)} changes.  The @command{make} call makes sure
@c @file{foo$(EXEEXT)} is up-to-date before @command{help2man}.  Another
@c way to ensure this would be to use separate directories for binaries
@c and man pages, and set @code{SUBDIRS} so that binaries are built
@c before man pages.
@c 
この方法では,@file{foo.1}は@file{foo$(EXEEXT)}が変更されるたびにリビ
ルドされません.@command{make}は@command{help2man}の前に
@file{foo$(EXEEXT)}を確実に更新します.これを確実にするもう一つの方法
は,バイナリとmanページに対して別のディレクトリを使用し,
@code{SUBDIRS}をmanページがビルドされる前にバイナリがビルドされるよう
に設定することです.

@c We could also decide not to distribute @file{foo.1}.  In
@c this case it's fine to have @file{foo.1} dependent upon
@c @file{foo$(EXEEXT)}, since both will have to be rebuilt.
@c However it would be impossible to build the package in a
@c cross-compilation, because building @file{foo.1} involves
@c an @emph{execution} of @file{foo$(EXEEXT)}.
@c 
@file{foo.1}を配布しないように決定することも可能です.この状況では,
@file{foo.1}が@file{foo$(EXEEXT)}に依存するようにすると両方ともリビル
ドされるので優れています.しかし,@file{foo.1}のビルドで
@file{foo$(EXEEXT)}を@emph{実行}するので,クロスコンパイルでパッケージ
をリビルドすることは不可能です.

@c Another context where such errors are common is when distributed files
@c are built by tools which are built by the package.  The pattern is similar:
@c 
そのようなエラーがあるもう一つの状況は,配布されるファイルがパッケージ
でビルドされるツールを用いてビルドされるときです.パターンは似ています.

@example
distributed-file: built-tools distributed-sources
        build-command
@end example

@noindent
@c should be changed to
@c 
以下のように変更すべきです.

@example
distributed-file: distributed-sources
        $(MAKE) $(AM_MAKEFLAGS) built-tools
        build-command
@end example

@noindent
@c or you could choose not to distribute @file{distributed-file}, if
@c cross-compilation does not matter.
@c 
または,クロスコンパイルで問題になる場合は@file{distributed-file}を配
布しないように選択することも可能です.

@c The points made through these examples are worth a summary:
@c 
これらの例に意味がある状況をまとめます.

@cartouche
@itemize
@item
@c Distributed files should never depend upon non-distributed built
@c files.
@c 
配布されるファイルは,配布されないがビルドはされるファイルに決して依存
すべきではない.
@item
@c Distributed files should be distributed will all their dependencies.
@c 
配布されるファイルは,その依存性で配布されるべきである.
@item
@c If a file is @emph{intended} be rebuilt by users, there is no point in
@c distributing it.
@c 
ファイルがユーザにリビルドされるよう@emph{意図される}場合,それを配布
する場所はない.
@end itemize
@end cartouche

@vrindex distcleancheck_listfiles
@c For desperate cases, it's always possible to disable this check by
@c setting @code{distcleancheck_listfiles} as documented in @ref{Dist}.
@c Make sure you do understand the reason why @code{make distcheck}
@c complains before you do this.  @code{distcleancheck_listfiles} is a
@c way to @emph{hide} errors, not to fix them.  You can always do better.
@c 
絶望的な状況では,@ref{Dist}で説明したように,
@code{distcleancheck_listfiles}を設定することで,この調査を利用不可能
にすることが可能です.こうする前に,@code{make distcheck}が文句を言う
理由を必ず理解して下さい.@code{distcleancheck_listfiles}は@emph{エラー} 
を隠す方法で,それを修正するものではありません.良いようにして下さい.

@node renamed objects
@c @section Why are object files sometimes renamed?
@section なぜオブジェクトファイルの名前を変更することがあるのですか?

@c This happens when per-target compilation flags are used.  Object
@c files need to be renamed just in case they would clash with object
@c files compiled from the same sources, but with different flags.
@c Consider the following example.
@c 
これは,ターゲットごとにコンパイルフラグが使用されているとき発生します.
オブジェクトファイルは,同じソースから異なるフラグを用いてコンパイルさ
れるオブジェクトが互いに壊されないように,名前を変更する必要があります.
以下の例を考えて下さい.

@example
bin_PROGRAMS = true false
true_SOURCES = generic.c
true_CPPFLAGS = -DEXIT_CODE=0
false_SOURCES = generic.c
false_CPPFLAGS = -DEXIT_CODE=1
@end example
@noindent
@c Obviously the two programs are built from the same source, but it
@c would be bad if they shared the same object, because @file{generic.o}
@c cannot be built with both @code{-DEXIT_CODE=0} *and*
@c @code{-DEXIT_CODE=1}.  Therefore @command{automake} outputs rules to
@c build two different objects: @file{true-generic.o} and
@c @file{false-generic.o}.
@c 
二つのプログラムが同じソースからコンパイルされ,同じオブジェクトが共有
される場合は問題になるのは明らかで,それは,@file{generic.o}は
@code{-DEXIT_CODE=0}@emph{と}@code{-DEXIT_CODE=1}の両方を用いてコンパ
イルすることが不可能だからです.このため,@command{automake}は二つの異
なるオブジェクト,@file{true-generic.o}と@file{false-generic.o}をビル
ドするルールを出力します.

@c @command{automake} doesn't actually look whether sources files are
@c shared to decide if it must rename objects.  It will just rename all
@c objects of a target as soon as it sees per-target compilation flags
@c are used.
@c 
@command{automake}は,オブジェクトファイルの名前を変更する必要があるか
どうかを決定するため,実際にはソースファイルが共有されているかどうかを
見ていません.ターゲットごとのコンパイルフラグを使用していることが判明
したときに,すべてのターゲットのオブジェクトの名前を変更するだけです.

@c It's OK to share object files when per-target compilation flags are not
@c used.  For instance @file{true} and @file{false} will both use
@c @file{version.o} in the following example.
@c 
ターゲットごとのコンパイルフラグが使用されていないときは,オブジェクト
ファイルを共有しても問題ありません.例えば以下の例のように,
@file{true}と@file{false}が両方とも@file{version.o}を使用しているとき
です.

@example
AM_CPPFLAGS = -DVERSION=1.0
bin_PROGRAMS = true false
true_SOURCES = true.c version.c
false_SOURCES = false.c version.c
@end example

@c Note that the renaming of objects is also affected by the
@c @code{_SHORTNAME} variable (@pxref{Program and Library Variables}).
@c 
オブジェクトファイルの名前の変更は,@code{_SHORTNAME}変数にも影響され
ることに注意して下さい(@pxref{Program and Library Variables}).


@node Multiple Outputs
@c @section Handling Tools that Produce Many Outputs
@section 多くの出力を生成するツールを処理する
@cindex multiple outputs, rules with
@cindex many outputs, rules with
@cindex rules with multiple outputs

@c This section describes a @command{make} idiom that can be used when a
@c tool produces multiple output files.  It is not specific to Automake
@c and can be used in ordinary @file{Makefile}s.
@c 
このセクションでは,複数の出力ファイルを生成するときに使用可能な
@command{make}の特色を記述します.それはAutomake特有のものではありませ
んが,通常の@file{Makefile}で使用することが可能です.

@c Suppose we have a program called @command{foo} that will read one file
@c called @file{data.foo} and produce two files named @file{data.c} and
@c @file{data.h}.  We want to write a @file{Makefile} rule that captures
@c this one-to-two dependency.
@c 
一つの@file{data.foo}というファイルを読み込み,二つの@file{data.c}と
@file{data.h}という名前のファイルを生成する,@command{foo}というプログ
ラムを想定します.我々は,以下の一つのものから二つのものへの依存をとら
える@file{Makefile}ルールを書こうとしています.

@c The naive rule is incorrect:
@c 
そのままのルールは間違っています.

@example
# This is incorrect.
data.c data.h: data.foo
        foo data.foo
@end example

@noindent
@c What the above rule really says is that @file{data.c} and
@c @file{data.h} each depend on @file{data.foo}, and can each be built by
@c running @code{foo data.foo}.  In other words it is equivalent to:
@c 
上記のルールが実際に伝えているのは,@file{data.c}と@file{data.h}がそれ
ぞれ@file{data.foo}に依存していて,それぞれが@code{foo data.foo}の実行
でビルド可能であるということです.言い替えると,以下と等価です.

@example
# We do not want this.
data.c: data.foo
        foo data.foo
data.h: data.foo
        foo data.foo
@end example

@noindent
@c which means that @command{foo} can be run twice.  Usually it will not
@c be run twice, because @command{make} implementations are smart enough
@c to check for the existence of the second file after the first one has
@c been built; they will therefore detect that it already exists.
@c However there are a few situations where it can run twice anyway:
@c 
これは,@command{foo}を二回実行するはずだということを意味します.
@command{make}の実装では,最初の一つがビルドされた後に二番目のファイル
の存在を調査するよう十分に賢いものなので,普通は二回実行されないでしょ
う.すなわち,すでに存在していることがわかっています.しかし,場合によっ
ては二回実行される可能性もあります.

@itemize
@item
@c The most worrying case is when running a parallel @command{make}.  If
@c @file{data.c} and @file{data.h} are built in parallel, two @code{foo
@c data.foo} commands will run concurrently.  This is harmful.
@c 
最も厄介な状況は,並行して@command{make}されるときです.@file{data.c} 
と@file{data.h}が並行してビルドされる場合,二回@code{foo data.foo}コマ
ンドが同時に実行されます.これは有害です.
@item
@c Another case is when the dependency (here @code{data.foo}) is
@c (or depends upon) a phony target.
@c 
もう一つの状況は,依存性(ここでは@code{data.foo})が偽のターゲットであ
る(またはそれに依存する)状況です.
@end itemize

@c A solution that works with parallel @command{make} but not with
@c phony dependencies is the following:
@c 
並列した@command{make}の動作を解決し,偽の依存性は解決できない方法とし
て以下のものがあります.

@example
data.c data.h: data.foo
        foo data.foo
data.h: data.c
@end example

@noindent
@c The above rules are equivalent to
@c 
上記のルールは以下と等価です.

@example
data.c: data.foo
        foo data.foo
data.h: data.foo data.c
        foo data.foo
@end example
@noindent
@c therefore a parallel @command{make} will have to serialize the builds
@c of @file{data.c} and @file{data.h}, and will detect that the second is
@c no longer needed once the first is over.
@c 
これで,並列した@command{make}は,@file{data.c}と@file{data.h}の連続し
たビルドになり,二番目は一回目で終っているので,もはや不要であることを
検出します.

@c Using this pattern is probably enough for most cases.  However it does
@c not scale easily to more output files (in this scheme all output files
@c must be totally ordered by the dependency relation), so we will
@c explore a more complicated solution.
@c 
このパターンを使用することで,おそらくほとんどの状況を十分満たすでしょ
う.しかし,出力ファイルが多くなるにつれ(この手法では,すべての出力ファ
イルを依存関係の完全な順番にする必要があり)難しくなるので,我々はより
複雑な解決方法を探りました.

@c Another idea is to write the following:
@c 
もう一つの考えは,以下のように書くことです.

@example
# There is still a problem with this one.
data.c: data.foo
        foo data.foo
data.h: data.c
@end example

@noindent
@c The idea is that @code{foo data.foo} is run only when @file{data.c}
@c needs to be updated, but we further state that @file{data.h} depends
@c upon @file{data.c}.  That way, if @file{data.h} is required and
@c @file{data.foo} is out of date, the dependency on @file{data.c} will
@c trigger the build.
@c 
この考えは,@code{foo data.foo}は@file{data.c}を更新する必要があるとき
だけ実行されますが,我々は,@file{data.h}が@file{data.c}に依存するとい
う一歩先の立場にいることになります.つまり,@file{data.h}が必要になり,
@file{data.foo}が古い場合,@file{data.c}の依存性によってビルドが開始さ
れるでしょう.

@c This is almost perfect, but suppose we have built @file{data.h} and
@c @file{data.c}, and then we erase @file{data.h}.  Then, running
@c @code{make data.h} will not rebuild @file{data.h}.  The above rules
@c just state that @file{data.c} must be up-to-date with respect to
@c @file{data.foo}, and this is already the case.
@c 
これでほとんど完璧ですが,我々は,@file{data.h}と@file{data.c}をビルド
しておき,その後で@file{data.h}を削除することを提案します.そうするこ
とで,@code{make data.h}のとき@file{data.h}はリビルドされません.上記
のルールでは,@file{data.foo}に対応して@file{data.c}は更新する必要があ
りますが,既にそうなっています.

@c What we need is a rule that forces a rebuild when @file{data.h} is
@c missing.  Here it is:
@c 
我々が必要なものは,@file{data.h}がないときにリビルドを強制するルール
です.以下のようにします.

@example
data.c: data.foo
        foo data.foo
data.h: data.c
        @@if test -f $@@; then :; else \
          rm -f data.c; \
          $(MAKE) $(AM_MAKEFLAGS) data.c; \
        fi
@end example

@c The above scales easily to more outputs and more inputs.  One of the
@c output is picked up to serve as a witness of the run of the command,
@c it depends upon all inputs, and all other outputs depend upon it.  For
@c instance if @command{foo} should additionally read @file{data.bar} and
@c also produce @file{data.w} and @file{data.x}, we would write:
@c 
上記では,出力と入力が多くなっても簡単です.出力の一つは,コマンド実行
の証拠として提供されるために必要なものが分かり,それはすべての入力に依
存し,それ以外の出力ファイルもすべてそれに依存します.例えば,
@command{foo}に@file{data.bar}の読み込みを追加し,@file{data.w}と
@file{data.x}も出力させる場合,以下のように書くでしょう.

@example
data.c: data.foo data.bar
        foo data.foo data.bar
data.h data.w data.x: data.c
        @@if test -f $@@; then :; else \
          rm -f data.c; \
          $(MAKE) $(AM_MAKEFLAGS) data.c; \
        fi
@end example

@c There is still a minor problem with this setup.  @command{foo} outputs
@c four files, but we do not know in which order these files are created.
@c Suppose that @file{data.h} is created before @file{data.c}.  Then we
@c have a weird situation.  The next time @command{make} is run,
@c @file{data.h} will appear older than @file{data.c}, the second rule
@c will be triggered, a shell will be started to execute the
@c @code{if...fi} command, but actually it will just execute the
@c @code{then} branch, that is: nothing.  In other words, because the
@c witness we selected is not the first file created by @command{foo},
@c @command{make} will start a shell to do nothing each time it is run.
@c 
この設定では,ちょっとした問題が残っています.@command{foo}の出力は四
つのファイルですが,これらのファイルが生成される順序が分かりません.
@file{data.h}が@file{data.c}の前に作成されると仮定します.そうなると奇
妙な状況に陥ります.次に@command{make}が実行されると,@file{data.h}は
@file{data.c}より古くなり,二番目のルールが開始され,シェルは
@code{if...fi}コマンドを実行しますが,実際には@code{then}の中だけが実
行され,すなわち何も起こりません.言い替えると,我々が選択した証拠は
@command{foo}が生成する最初のファイルではないので,@command{make}は実
行しても何もしないシェルを開始します.

@c A simple riposte is to fix the timestamps when this happens.
@c 
簡単な答えは,これが生じたときにタイムスタンプを修正することです.

@example
data.c: data.foo data.bar
        foo data.foo data.bar
data.h data.w data.x: data.c
        @@if test -f $@@; then \
          touch $@@; \
        else \
          rm -f data.c; \
          $(MAKE) $(AM_MAKEFLAGS) data.c; \
        fi
@end example

@c Another solution, not incompatible with the previous one, is to use a
@c different and dedicated file as witness, rather than using any of
@c @command{foo}'s outputs.
@c 
もう一つの解決方法は,以前のものとは互換性がありませんが,
@command{foo}の出力するものではなく,別の専用ファイルを証拠として使用
することです.

@example
data.stamp: data.foo data.bar
        @@rm -f data.tmp
        @@touch data.tmp
        foo data.foo data.bar
        @@mv -f data.tmp $@@
data.c data.h data.w data.x: data.stamp
        @@if test -f $@@; then \
          touch $@@; \
        else \
          rm -f data.stamp; \
          $(MAKE) $(AM_MAKEFLAGS) data.stamp; \
        fi
@end example

@c @file{data.tmp} is created before @command{foo} is run, so it has a
@c timestamp older than output files output by @command{foo}.  It is then
@c renamed to @file{data.stamp} after @command{foo} has run, because we
@c do not want to update @file{data.stamp} if @command{foo} fails.
@c 
@command{foo}が実行される前に@file{data.tmp}が作成されるので,そのタイ
ムスタンプは@command{foo}が出力するファイルより古くなります.そして,
@command{foo}が失敗した場合は@file{data.stamp}を更新したくないので,
@file{data.stamp}を@command{foo}の実行後に名前を変更します.

@c Using a dedicated witness like this is very handy when the list of
@c output files is not known beforehand.  As an illustration, consider
@c the following rules to compile many @file{*.el} files into
@c @file{*.elc} files in a single command.  It does not matter how
@c @code{ELFILES} is defined (as long as it is not empty: empty targets
@c are not accepted by POSIX).
@c 
このような専用の証拠を使用することで,出力ファイルのリストが前もって分
からないときも簡単に処理できます.例として,単一のコマンドで,たくさん
の@file{*.el}ファイルを@file{*.elc}にコンパイルする,以下のルールを考
えてください.@code{ELFILES}の定義方法は(それが空ではない限り)問題にな
りません(空のターゲットはPOSIXでは受け入れられません).

@example
ELFILES = one.el two.el three.el @dots{}
ELCFILES = $(ELFILES:=c)

elc-stamp: $(ELFILES)
        @@rm -f elc-temp
        @@touch elc-temp
        $(elisp_comp) $(ELFILES)
        @@mv -f elc-temp $@@

$(ELCFILES): elc-stamp
        @@if test -f $@@; then \
          touch $@@; \
        else \
          rm -f elc-stamp; \
          $(MAKE) $(AM_MAKEFLAGS) elc-stamp; \
        fi
@end example

@c For completeness it should be noted that GNU @command{make} is able to
@c express rules with multiple output files using pattern rules
@c (@pxref{Pattern Examples, , Pattern Rule Examples, make, The GNU Make
@c Manual}).  We do not discuss pattern rules here because they are not
@c portable, but they can be convenient in packages that assume GNU
@c @command{make}.
@c 
仕上げに,GNU @command{make}は,パターンルールを使用することで複数の出
力ファイルを用いたルールを表現することが可能です(@pxref{Pattern
Examples, , Pattern Rule Examples, make, The GNU Make Manual}).パター
ンルールは移植性がないので,我々はここで議論しませんが,GNU
@command{make}を想定したパッケージでは便利になるはずです.

@c ========================================================== Appendices

@page
@node Copying This Manual
@c @appendix Copying This Manual
@appendix このマニュアルのコピーについて

@menu
* GNU Free Documentation License::  License for copying this manual
@end menu

@include fdl.texi

@page
@node Indices
@c @appendix Indices
@appendix 索引

@menu
* Macro and Variable Index::    Index of Autoconf macros and Automake variables
* General Index::               General index
@end menu

@node Macro and Variable Index
@c @appendixsec Macro and Variable Index
@appendixsec マクロと変数の索引

@printindex vr

@node General Index
@c @appendixsec General Index
@appendixsec 一般的な索引

@printindex cp


@page
@contents
@bye

@c  LocalWords:  texinfo setfilename settitle setchapternewpage texi direntry
@c  LocalWords:  dircategory in's aclocal ifinfo titlepage Tromey vskip pt sp
@c  LocalWords:  filll defcodeindex ov cv op tr syncodeindex fn cp vr ifnottex
@c  LocalWords:  dir Automake's ac Dist Gnits gnits cygnus dfn Autoconf's pxref
@c  LocalWords:  cindex Autoconf autoconf perl samp cvs dist trindex SUBST foo
@c  LocalWords:  xs emph FIXME ref vindex pkglibdir pkgincludedir pkgdatadir mt
@c  LocalWords:  pkg libdir cvindex cpio bindir sbindir rmt pax sbin zar zardir
@c  LocalWords:  HTML htmldir html noinst TEXINFOS nodist nobase strudel CFLAGS
@c  LocalWords:  libmumble CC YFLAGS ansi knr itemx de fication config url comp
@c  LocalWords:  depcomp elisp sh mdate mkinstalldirs mkdir py tex dvi ps pdf
@c  LocalWords:  ylwrap zardoz INIT gettext acinclude mv FUNCS LIBOBJS LDADD fr
@c  LocalWords:  uref featureful dnl src LINGUAS es ko nl pl sl sv PROG ISC doc
@c  LocalWords:  POSIX STDC fcntl FUNC ALLOCA blksize struct stat intl po chmod
@c  LocalWords:  ChangeLog SUBDIRS gettextize gpl testdata getopt INTLLIBS cpp
@c  LocalWords:  localedir datadir DLOCALEDIR DEXIT CPPFLAGS autoreconf opindex
@c  LocalWords:  AUX var symlink deps Wno Wnone package's aclocal's distclean
@c  LocalWords:  ltmain xref LIBSOURCE LIBSOURCES LIBOBJ MEMCMP vs RANLIB CXX
@c  LocalWords:  LDFLAGS LIBTOOL libtool XTRA LIBS gettext's acdir APIVERSION
@c  LocalWords:  dirlist noindent usr MULTILIB multilib Multilibs TIOCGWINSZ sc
@c  LocalWords:  GWINSZ termios SRCDIR tarball bzip LISPDIR lispdir XEmacs CCAS
@c  LocalWords:  emacsen MicroEmacs CCASFLAGS UX GCJ gcj GCJFLAGS posix DMALLOC
@c  LocalWords:  dmalloc ldmalloc REGEX regex rx DEPDIR DEP DEFUN aclocaldir fi
@c  LocalWords:  mymacro myothermacro AMFLAGS autopoint autogen libtoolize yum
@c  LocalWords:  autoheader README MAKEFLAGS subdir Inetutils sync COND endif
@c  LocalWords:  Miller's installable includedir inc pkgdata EXEEXT libexec bsd
@c  LocalWords:  pkglib libexecdir prog libcpio cpio's dlopen dlpreopen linux
@c  LocalWords:  subsubsection OBJEXT esac lib LTLIBRARIES liblob LIBADD AR ar
@c  LocalWords:  ARFLAGS cru ing maude libgettext lo LTLIBOBJS rpath SGI PRE yy
@c  LocalWords:  libmaude CCLD CXXFLAGS FFLAGS LFLAGS OBJCFLAGS RFLAGS DEFS cc
@c  LocalWords:  SHORTNAME vtable srcdir nostdinc basename yxx cxx ll lxx gdb
@c  LocalWords:  lexers yymaxdepth maxdepth yyparse yylex yyerror yylval lval
@c  LocalWords:  yychar yydebug yypact yyr yydef def yychk chk yypgo pgo yyact
@c  LocalWords:  yyexca exca yyerrflag errflag yynerrs nerrs yyps yypv pv yys
@c  LocalWords:  yystate yytmp tmp yyv yyval val yylloc lloc yyreds yytoks toks
@c  LocalWords:  yylhs yylen yydefred yydgoto yysindex yyrindex yygindex yyname
@c  LocalWords:  yytable yycheck yyrule byacc CXXCOMPILE CXXLINK FLINK cfortran
@c  LocalWords:  Catalogue preprocessable FLIBS libfoo baz JAVACFLAGS java exe
@c  LocalWords:  SunOS fying basenames exeext uninstalled oldinclude kr FSF's
@c  LocalWords:  pkginclude oldincludedir sysconf sharedstate localstate gcc rm
@c  LocalWords:  sysconfdir sharedstatedir localstatedir preexist CLEANFILES gz
@c  LocalWords:  unnumberedsubsec depfile tmpdepfile depmode const interoperate
@c  LocalWords:  JAVAC javac JAVAROOT builddir CLASSPATH ENV pyc pyo pkgpython
@c  LocalWords:  pyexecdir pkgpyexecdir Python's pythondir pkgpythondir txi ois
@c  LocalWords:  installinfo vers MAKEINFO makeinfo MAKEINFOFLAGS noinstall rf
@c  LocalWords:  mandir thesame alsothesame installman myexecbin DESTDIR Pinard
@c  LocalWords:  uninstall installdirs uninstalls MOSTLYCLEANFILES mostlyclean
@c  LocalWords:  DISTCLEANFILES MAINTAINERCLEANFILES gzip'd GZIP gzip shar exp
@c  LocalWords:  distdir distcheck distcleancheck listfiles distuninstallcheck
@c  LocalWords:  VPATH tarfile stdout XFAIL DejaGnu dejagnu DEJATOOL runtest ln
@c  LocalWords:  RUNTESTDEFAULTFLAGS toolchain RUNTESTFLAGS asis readme DVIPS
@c  LocalWords:  installcheck gzipped tarZ std utils etags mkid multilibbing cd
@c  LocalWords:  ARGS taggable ETAGSFLAGS lang ctags CTAGSFLAGS GTAGS gtags idl
@c  LocalWords:  foocc doit idlC multilibs ABIs cmindex defmac ARG enableval
@c  LocalWords:  MSG xtrue DBG pathchk CYGWIN afile proglink versioned CVS's
@c  LocalWords:  wildcards Autoconfiscated subsubheading autotools Meyering API
@c  LocalWords:  ois's wildcard Wportability cartouche vrindex printindex Duret
@c  LocalWords:  DSOMEFLAG DVERSION automake Lutz insertcopying versioning FAQ
@c  LocalWords:  LTLIBOBJ Libtool's libtool's libltdl dlopening itutions libbar
@c  LocalWords:  WANTEDLIBS libhello sublibraries libtop libsub dlopened Ratfor
@c  LocalWords:  mymodule timestamps timestamp underquoted MAKEINFOHTMLFLAGS
@c  LocalWords:  GNUmakefile buildir Subpackages subpackage's subpackages

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>