Automake是一個(gè)從文件`Makefile.am'自動(dòng)生成`Makefile.in' 的工具。每個(gè)`Makefile.am'基本上是一系列make的宏定義（make規(guī)則也會(huì)偶爾出現(xiàn)）。生成的`Makefile.in's服從GNU Makefile標(biāo)準(zhǔn)。

GNU Makefile標(biāo)準(zhǔn)文檔（參見GNU編碼標(biāo)準(zhǔn)中的‘Makefile慣例’節(jié)）長、復(fù)雜，而且會(huì)發(fā)生改變。Automake的目的就是解除個(gè)人GNU維護(hù)者維護(hù)Makefile的負(fù)擔(dān)（并且讓Automake的維護(hù)者來承擔(dān)這個(gè)負(fù)擔(dān)）。

典型的Automake輸入文件是一系列簡單的宏定義。處理所有這樣的文件以創(chuàng)建 `Makefile.in'。在一個(gè)項(xiàng)目（project）的每個(gè)目錄中通常包含一個(gè) `Makefile.am'。

Automake在幾個(gè)方面對一個(gè)項(xiàng)目做了限制；例如它假定項(xiàng)目使用Autoconf （參見Autoconf手冊），并且對`configure.in'的內(nèi)容施加了某些限制。

為生成`Makefile.in'，Automake需要perl。但是由Automake創(chuàng)建的發(fā)布完全服從GNU標(biāo)準(zhǔn)，并且在創(chuàng)建中不需要perl。

請把關(guān)于Automake的建議和bug發(fā)送到 automake-bugs@gnu.org。

通用性概念

一些基本概念將有助于理解Automake是如何工作的。

通用操作

Automake讀入`Makefile.am'并且生成`Makefile.in'。在`Makefile.am'中定義的一些宏和目標(biāo)（targets）指揮automake生成更多特定的代碼；例如一個(gè)`bin_PROGRAMS'宏定義將生成一個(gè)需要被編譯、連接的目標(biāo)。

`Makefile.am'中的宏定義和目標(biāo)被復(fù)制到生成的文件中。這使得你可以把任何代碼添加到生成的`Makefile.in'文件中。例如，Automake的發(fā)布包含了非標(biāo)準(zhǔn)的cvs-dist目標(biāo)，Automake的維護(hù)者用它從他的版本控制系統(tǒng)中創(chuàng)建發(fā)布版本。

Automake不能識別GNU對make的擴(kuò)展。在`Makefile.am'中使用這些擴(kuò)展將導(dǎo)致錯(cuò)誤或者令人不解的行為。

Automake試圖明智地把注釋和相鄰的目標(biāo)（或者變量定義）關(guān)聯(lián)起來。

在`Makefile.am'中定義的目標(biāo)通常覆蓋了所有由automake 自動(dòng)生成的擁有相似名字的目標(biāo)。雖然Automake提供了這一功能，但最好避免使用它，因?yàn)橛行r(shí)候生成的規(guī)則將是十分特別的。

類似地，在`Makefile.am'中定義的變量將覆蓋任何通常由automake 創(chuàng)建的變量定義。該功能比覆蓋目標(biāo)定義的功能要常用得多。需要警告的是許多由 automake生成的變量都被認(rèn)為是內(nèi)部使用的，并且它們的名字可能在未來的版本中改變。

在檢驗(yàn)變量定義的時(shí)候，Automake將遞歸地檢驗(yàn)定義中的變量引用。例如，如果Automake 在如下片斷中搜索`foo_SOURCES'的內(nèi)容。

xs = a.c b.c
foo_SOURCES = c.c $(xs)

它將把文件`a.c'、 `b.c'和 `c.c'作為`foo_SOURCES' 的內(nèi)容。

Automake還允許給出不被復(fù)制到輸出中的注釋；所有以`##'開頭的行將被Automake徹底忽略。

作為慣例，`Makefile.am'的第一行是：

## Process this file with automake to produce Makefile.in

深度

automake支持三種目錄層次： “flat”、“shallow”和“deep”。

一個(gè)flat（平）包指的是所有文件都在一個(gè)目錄中的包。為這類包提供的`Makefile.am' 缺少宏SUBDIRS。這類包的一個(gè)例子是termutils。

一個(gè)deep（深）包指的是所有的源代碼都被儲存在子目錄中的包；頂層目錄主要包含配置信息。GNU cpio 是這類包的一個(gè)很好的例子，GNU tar也是。deep包的頂層`Makefile.am'將包括宏SUBDIRS，但沒有其它定義需要?jiǎng)?chuàng)建的對象的宏。

一個(gè)shallow（淺）包指的是主要的源代碼儲存在頂層目錄中，而各個(gè)部分（典型的是庫）則儲存在子目錄中的包。Automake本身就是這類包（GNU make也是如此，它現(xiàn)在已經(jīng)不使用automake）。

嚴(yán)格性

Automake的目的是用于維護(hù)GNU包，它為適應(yīng)那些希望使用它的人做出了一些努力，但并不指望應(yīng)用所有的GNU慣例。

按照這個(gè)目標(biāo)，Automake支持三級嚴(yán)格性---嚴(yán)格性指的是Automake 將如何檢查包所服從的標(biāo)準(zhǔn)。

可用的嚴(yán)格性級別有：

`foreign'（外來）

Automake將僅僅檢查那些為保證正確操作所必需的事項(xiàng)。例如，盡管GNU標(biāo)準(zhǔn)指出文件`NEWS'必須存在，在本方式下，并不需要它。該模式名來自于Automake 是被設(shè)計(jì)成用于GNU程序的事實(shí)的；它放松了標(biāo)準(zhǔn)模式的操作規(guī)則。

`gnu'

Automake將盡可能地檢查包是否服從GNU標(biāo)準(zhǔn)。這是缺省設(shè)置。

`gnits'

Automake將按照還沒有完成的Gnits標(biāo)準(zhǔn)進(jìn)行檢查。它們是基于GNU標(biāo)準(zhǔn)的，但更加詳盡。除非你是Gnits標(biāo)準(zhǔn)的參與奉獻(xiàn)者，我們建議您在Gnits標(biāo)準(zhǔn)正式出版之前不要使用這一選項(xiàng)。

關(guān)于嚴(yán)格性級別的精確含義的詳細(xì)說明，參見--gnu 和--gnits的效果

統(tǒng)一命名機(jī)制

Automake變量通常服從統(tǒng)一的命名機(jī)制，以易于確定如何創(chuàng)建和安裝程序（和其它派生對象）。這個(gè)機(jī)制還支持在運(yùn)行configure的時(shí)候確定應(yīng)該創(chuàng)建那些對象。

在運(yùn)行make時(shí)，某些變量被用于確定應(yīng)該創(chuàng)建那些對象。這些變量被稱為主（primary）變量。例如，主變量PROGRAMS 保存了需要被編譯和連接的程序的列表。

另一組變量用于確定應(yīng)該把創(chuàng)建了的對象安裝在哪里。這些變量在主變量之后命名，但是含有一個(gè)前綴以指出那個(gè)標(biāo)準(zhǔn)目錄將作為安裝目錄。標(biāo)準(zhǔn)目錄名在GNU標(biāo)準(zhǔn)中給出（參見GNU編碼標(biāo)準(zhǔn)中的`為Directory Variables'節(jié)）。 Automake用pkglibdir、pkgincludedir和 pkgdatadir擴(kuò)展了這個(gè)列表；除了把`@PACKAGE@'附加其后之外，與非`pkg'版本是相同的。例如，pkglibdir被定義為$(datadir)/@PACKAGE@.

對于每個(gè)主變量，還有一個(gè)附加的變量，它的名字是在主變量名之前加一個(gè)`EXTRA_'。該變量用于儲存根據(jù)configure的運(yùn)行結(jié)果，可能創(chuàng)建、也可能不創(chuàng)建的對象列表。引入該變量是因?yàn)锳utomake必須靜態(tài)地知道需要?jiǎng)?chuàng)建的對象的完整列表以創(chuàng)建在所有情況下都能夠工作的`Makefile.in'。

例如，在配置時(shí)刻cpio確定創(chuàng)建哪些程序。一部分程序被安裝在bindir，還有一部分程序被安裝在sbindir：

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

定義沒有前綴的主變量（比如說PROGRAMS）是錯(cuò)誤的。

在構(gòu)造變量名的時(shí)候，通常省略后綴`dir'；因此我們使用 `bin_PROGRAMS'而不是`bindir_PROGRAMS'.

不是每種對象都可以安裝在任何目錄中。Automake將記錄它們以試圖找出錯(cuò)誤。Automake還將診斷目錄名中明顯的拼寫錯(cuò)誤。

有時(shí)標(biāo)準(zhǔn)目錄--即使在Automake擴(kuò)展之后---是不夠的。特別在有些時(shí)候，為了清晰起見，把對象安裝到預(yù)定義目錄的子目錄中是十分有用的。為此，Automake允許你擴(kuò)展可能的安裝目錄列表。如果定義了一個(gè)添加了后綴`dir'的變量（比如說`zardir'），則給定的前綴（比如`zar'）就是合法的。

例如，在HTML支持成為Automake的一部分之前，你可以使用它安裝原始的HTML文檔。

htmldir = $(prefix)/html
html_DATA = automake.html

特殊前綴`noinst'表示根本不會(huì)安裝這些有問題的對象。

特殊前綴`check'表示僅僅在運(yùn)行make check 命令的時(shí)候才創(chuàng)建這些有問題的對象。

可能的主變量名有`PROGRAMS'、`LIBRARIES'、 `LISP'、`SCRIPTS'、`DATA'、 `HEADERS'、`MANS'和`TEXINFOS'。

派生變量是如何命名的

有時(shí)Makefile變量名是從用戶提供的某些文本中派生而來的。例如程序名被重寫到Makefile宏名中。Automake把這些文本規(guī)范化，以使它可以不必服從Makefile的變量名規(guī)則。在名字中除了字母、數(shù)字和下劃線之外的所有字符都將用下劃線代替。例如，如果你的程序被命名為sniff-glue，那么派生出的變量名將是sniff_glue_SOURCES，而不是sniff-glue_SOURCES。

一些實(shí)例軟件包

一個(gè)簡單的例子，從起點(diǎn)到終點(diǎn)

讓我們假定你剛剛寫完zardoz，一個(gè)是你的頭從一個(gè)漩渦漂流到另一個(gè)漩渦的程序。你已經(jīng)使用了autoconf以提供一個(gè)可移植的框架，但你的`Makefile.in'還未完成，所以你需要automake。

第一步是更新你的`configure.in'以包含automake需要的命令。完成這一步的最簡單方式是在AC_INIT之后添加AM_INIT_AUTOMAKE：

AM_INIT_AUTOMAKE(zardoz, 1.0)

因?yàn)槟愕某绦虿缓腥魏螐?fù)雜性的因素（例如，它不使用gettext，它不需要共享庫），你已經(jīng)完成了這一步工作。很容易吧！

現(xiàn)在你必須重新生成`configure'。但為此，你需要告訴autoconf 如何找到你使用的新宏。完成該任務(wù)的最簡單的方式是使用aclocal程序?yàn)槟闵赡愕?tt>`aclocal.m4'。但是等等...你已經(jīng)有了一個(gè)`aclocal.m4'，這是因?yàn)槟惚仨殲槟愕某绦驅(qū)懸恍┖辍?code>aclocal允許你把你自己的宏放到 `acinclude.m4'中去，所以簡單地改名并且運(yùn)行：

mv aclocal.m4 acinclude.m4
aclocal
autoconf

現(xiàn)在是你為zardoz寫的`Makefile.am'的時(shí)候了。 zardoz是一個(gè)用戶程序，所以你需要把它安裝到其它用戶程序安裝的地方去。 zardoz還有一些Texinfo文檔。你的`configure.in'腳本使用 AC_REPLACE_FUNCS，因此你需要與`@LIBOBJS@'連接。所以這里你寫：

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

現(xiàn)在你運(yùn)行automake --add-missing以生成你的`Makefile.in' 并且得到任何你可能需要的附加文件，現(xiàn)在你完成了你的任務(wù)！

一個(gè)經(jīng)典的程序

hello因?yàn)樗?jīng)典的簡單性和多用性而出名。本節(jié)展示Automake將被如何用于Hello包。下面的例子來自于最新的GNU Hello，但剔除了所有僅為維護(hù)者使用的代碼和所有的版權(quán)注釋。

當(dāng)然，GNU Hello比您的傳統(tǒng)的兩行的代碼具有更多的特征。GNU Hello是國際化的，進(jìn)行選項(xiàng)處理，并且含有一個(gè)手冊和一個(gè)測試套件。GNU Hello是一個(gè)deep包。

這里是來自于GNU Hello的`configure.in'：

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])

宏`AM_'由Automake（或者Gettext庫）提供；其它的是標(biāo)準(zhǔn)Autoconf宏。

頂層`Makefile.am'：

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

就像你所見到的，這里的所有工作實(shí)際上都是在子目錄中完成的。

`po'和`intl'目錄是gettextize自動(dòng)生成的；在這里我們不討論它們。

在`doc/Makefile.am'中我們看到：

info_TEXINFOS = hello.texi
hello_TEXINFOS = gpl.texi

它足以創(chuàng)建、安裝并且發(fā)布Hello手冊。

這里是`tests/Makefile.am':

TESTS = hello
EXTRA_DIST = hello.in testdata

腳本`hello'是由configure生成的，并且僅僅在測試時(shí)才生成。 make check將運(yùn)行這個(gè)測試。

最后我們有`src/Makefile.am'，所有實(shí)際工作在此完成：

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)\"

創(chuàng)建etags和ctags

這里是另一個(gè)復(fù)雜一些的例子。它展示了如何從同一個(gè)源文件（`etags.c'）生成兩個(gè)程序（ctags和etags）。困難的部分是對 `etags.c'的每個(gè)編譯需要不同的cpp選項(xiàng)。

bin_PROGRAMS = etags ctags
ctags_SOURCES =
ctags_LDADD = ctags.o
etags.o: etags.c
$(COMPILE) -DETAGS_REGEXPS -c etags.c
ctags.o: etags.c
$(COMPILE) -DCTAGS -o ctags.o -c etags.c

其中ctags_SOURCES被定義為空--這種方式表明沒有替換隱含的值然而，隱含的值被用于從`etags.o'生成etags。

ctags_LDADD用于把`ctags.o'添加到連接行中。 ctags_DEPENDENCIES由Automake生成。

如果你的編譯器不接受`-c'和`-o'，那么上述規(guī)則將不能工作。對此，最簡單的修正是引入偽依賴（bogus dependency）（以避免由并行 make所導(dǎo)致的問題）：

etags.o: etags.c ctags.o
$(COMPILE) -DETAGS_REGEXPS -c etags.c
ctags.o: etags.c
$(COMPILE) -DCTAGS -c etags.c && mv etags.o ctags.o

同樣，如果使用了de-ANSI-fication的特征，這些顯式規(guī)則將不能工作；支持它需要一些更多的工作：

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

創(chuàng)建`Makefile.in'

為了為一個(gè)包創(chuàng)建所有的`Makefile.in'，在頂層目錄不帶任何參數(shù)地運(yùn)行automake。 automake將自動(dòng)地尋找每個(gè)合適的`Makefile.am'（通過掃描 `configure.in'；參見掃描`configure.in'）并生成相應(yīng)的`Makefile.in'。automake認(rèn)為包的組成是相當(dāng)簡單的；它假定包僅僅在頂層目錄含有一個(gè)`configure.in'。如果你的包含有多個(gè) `configure.in'，那么你必須在每個(gè)含有`configure.in'的目錄中運(yùn)行automake。

你偶爾可能需要給automake參數(shù)；`.am'被添加到參數(shù)之后并且其結(jié)果將作為輸入文件名。該特征通常僅僅用于自動(dòng)重新創(chuàng)建一個(gè)過時(shí)的 `Makefile.in'。automake必須總是在項(xiàng)目的最頂層目錄中運(yùn)行，即使用于重新生成某些子目錄中的`Makefile.in'也是如此。這是因?yàn)?code>automake必須掃描`configure.in'，并且因?yàn)樵谀承┣闆r下，automake根據(jù)`Makefile.in'在子目錄中這一情況確定它的行為。

automake接受以下選項(xiàng)：

-a

--add-missing

Automake要求一些通用文件在特定的位置存在。例如如果`configure.in'運(yùn)行了AC_CANONICAL_HOST，就需要`config.guess'。 Automake與幾個(gè)這樣的文件一同發(fā)布；只要可能，該選項(xiàng)將把缺少的文件自動(dòng)添加到包中。通常如果Automake告訴你缺少文件，試一下本選項(xiàng)。

--amdir=dir

在dir中而不是安裝目錄中，尋找Automake數(shù)據(jù)文件，它通常用于調(diào)試。

--build-dir=dir

告訴Automake創(chuàng)建目錄在那里。本選項(xiàng)在把依賴性添加到由make dist生成的 `Makefile.in'中的時(shí)候使用；在其它情況下不應(yīng)該使用它。

--cygnus

按照Cygnus規(guī)則，而不是GNU或者Gnits規(guī)則，生成`Makefile.in'，詳情請參見--cygnus的效果。

--foreign

把全局嚴(yán)格性設(shè)置成`foreign'。詳情請參見嚴(yán)格性。

--gnits

把全局嚴(yán)格性設(shè)置成`gnits'。詳情請參見 --gnu和--gnits的效果

--gnu

把全局嚴(yán)格性設(shè)置成`gnu'。詳情請參見 --gnu和--gnits的效果。這是缺省嚴(yán)格性。

--help

打印命令行選項(xiàng)的概述并且退出。

-i

--include-deps

包含生成的`Makefile.in'中所有自動(dòng)生成的依賴信息（參見自動(dòng)的依賴性跟蹤）。通常在制作發(fā)布版本時(shí)使用；參見需要發(fā)布哪些文件。

--generate-deps

生成一個(gè)連接了所有自動(dòng)生成的依賴信息的文件（參見 自動(dòng)的依賴性跟蹤）文件，`.dep_segment'。通常在制作發(fā)布版本時(shí)使用；參見需要發(fā)布哪些文件。在維護(hù)為其它平臺所制作的`SMakefile'或者makefile（`Makefile.DOS'，等等，）時(shí)是有用的。它只能與--include-deps、--srcdir-name 和--build-dir一同使用。如果給出了本選項(xiàng)，不會(huì)實(shí)行任何其他處理。

--no-force

通常automake創(chuàng)建在`configure.in'中提到的所有 `Makefile.in'。本選項(xiàng)僅僅更新那些按照它們的依賴性過時(shí)了的 `Makefile.in'。

-o dir

--output-dir=dir

把生成的`Makefile.in'放到目錄dir中。通常每個(gè)`Makefile.in'在對應(yīng)的`Makefile.am'所在的目錄中創(chuàng)建。本選項(xiàng)被用于創(chuàng)建發(fā)布版本。

--srcdir-name=dir

告訴Automake與當(dāng)前任務(wù)相關(guān)的源代碼目錄名。本選項(xiàng)在把依賴性引入由make dist生成的`Makefile.in'中時(shí)使用；它不應(yīng)被用于其它情況。

-v

--verbose

讓Automake打印關(guān)于被讀入或創(chuàng)建的文件的信息。

--version

打印Automake的版本號并且退出。

掃描`configure.in'

Automake掃描包的`configure.in'以確定關(guān)于包的一些信息。 Automake需要一些autoconf宏并且一些變量必須在 `configure.in'中定義。Automake還用來自`configure.in' 的信息以進(jìn)一步修整它的輸出。

為了簡化維護(hù)，Automake還支持一些autoconf宏。通過使用程序aclocal，可以自動(dòng)地把這些宏附加到你的`aclocal.m4'中。

配置需求

達(dá)到Automake要求的最簡單方式就是使用宏AM_INIT_AUTOMAKE （參見由Automake支持的Autoconf宏）。但是如果你愿意，你可以手工完成所需的各個(gè)步驟：

• 用AC_SUBST定義變量PACKAGE和VERSION。 PACKAGE應(yīng)該是在捆綁發(fā)布的時(shí)候使用的包的名稱。例如，Automake把PACKAGE定義成`automake'。 VERSION應(yīng)該是被開發(fā)的版本的版本號。我們建議你僅僅在你的包中定義版本號的地方創(chuàng)建`configure.in'；這使得發(fā)布簡單化了。 除非在`Gnits'模式（參見 --gnu和--gnits的效果），Automake 不會(huì)對PACKAGE或者VERSION進(jìn)行任何解釋。
• 如果要安裝一個(gè)程序或者一個(gè)腳本，使用宏AC_ARG_PROGRAM。
• 如果包不是平（flat）的，使用宏AC_PROG_MAKE_SET。
• 使用宏AM_SANITY_CHECK以確認(rèn)創(chuàng)建環(huán)境的完整性。
• 如果包安裝了任何腳本（參見可執(zhí)行的腳本），使用宏AM_PROG_INSTALL。否則，使用AC_PROG_INSTALL。
• 使用AM_MISSING_PROG以確認(rèn)在創(chuàng)建環(huán)境中，程序aclocal、 autoconf、automake、autoheader 和makeinfo是否存在。下面是如何完成這個(gè)任務(wù)：

  missing_dir=`cd $ac_aux_dir && pwd`
      AM_MISSING_PROG(ACLOCAL, aclocal, $missing_dir)
      AM_MISSING_PROG(AUTOCONF, autoconf, $missing_dir)
      AM_MISSING_PROG(AUTOMAKE, automake, $missing_dir)
      AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir)
      AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
      

這里是Automake需要的，但是沒有被AM_INIT_AUTOMAKE運(yùn)行的其它宏：

AC_OUTPUT

Automake用它確定創(chuàng)建那個(gè)文件。列出的名為Makefile的文件作為`Makefile'處理。對其它列出的文件進(jìn)行不同的處理。目前唯一的不同是`Makefile'將被make distclean 刪除，而其它的文件將被make clean刪除。

Automake能夠識別的其它事情

Automake還將能夠識別某些宏的使用并且適當(dāng)?shù)匦拚傻?tt>`Makefile.in'。目前能夠識別的宏以及它們的效果是：

AC_CONFIG_HEADER

Automake要求使用AM_CONFIG_HEADER，它類似于AC_CONFIG_HEADER 而且完成一些有用的Automake特定的工作。

AC_CONFIG_AUX_DIR

Automake將在調(diào)用本宏時(shí)命名的目錄中尋找各種求助腳本，例如`mkinstalldirs'。如果沒找到，將在其它標(biāo)準(zhǔn)的位置（頂層目錄中，或者在對應(yīng)與當(dāng)前`Makefile.am' 的源代碼目錄，任何一個(gè)都是合適的）中尋找腳本。 請幫助我：以給出尋找該目錄的完整列表。

AC_PATH_XTRA

Automake將把由AC_PATH_XTRA定義的變量的定義插入每個(gè)創(chuàng)建C程序或者庫的`Makefile.in'中。

AC_CANONICAL_HOST

AC_CHECK_TOOL

Automake將確認(rèn)`config.guess'和`config.sub'的存在。并且將引入`Makefile'變量`host_alias'和 `host_triplet'。

AC_CANONICAL_SYSTEM

它類似于AC_CANONICAL_HOST，此外還定義了`Makefile' 變量`build_alias'和`target_alias'。

AC_FUNC_ALLOCA

AC_FUNC_GETLOADAVG

AC_FUNC_MEMCMP

AC_STRUCT_ST_BLOCKS

AC_FUNC_FNMATCH

AM_FUNC_STRTOD

AC_REPLACE_FUNCS

AC_REPLACE_GNU_GETOPT

AM_WITH_REGEX

Automake將確認(rèn)為對應(yīng)于這些宏的對象生成了適當(dāng)?shù)囊蕾囮P(guān)系。此外，Automake將驗(yàn)證適當(dāng)?shù)脑次募蔀榘l(fā)布的一部分。使用這些宏，Automake并不需要任何C源代碼，所以automake -a 將不會(huì)安裝源代碼。詳情請參見創(chuàng)建一個(gè)庫

LIBOBJS

Automake將檢測把`.o'文件添加到LIBOBJS中的語句，并且按照與在AC_REPLACE_FUNCS中發(fā)現(xiàn)的文件相同的方式處理這些附加的文件。

AC_PROG_RANLIB

如果在包中創(chuàng)建了任何庫，就需要它。

AC_PROG_CXX

如果包含了任何C++源代碼，就需要它。

AM_PROG_LIBTOOL

Automake將啟動(dòng)為libtool所做的處理（參見Libtool手冊）。

AC_PROG_YACC

如果找到了Yacc源文件，那么你必須使用這個(gè)宏或者在`configure.in' 中定義變量`YACC'。前者更好一些。

AC_DECL_YYTEXT

如果在包中有Lex源代碼，需要使用這個(gè)宏。

AC_PROG_LEX

如果找到了Lex源代碼，那么必須使用本宏。

ALL_LINGUAS

如果Automake發(fā)現(xiàn)在`configure.in'中設(shè)置了該變量，它將檢查目錄`po'以確認(rèn)所有命名了的`.po' 文件都是存在的，并且所有存在的`.po'文件都被命了名。

AM_C_PROTOTYPES

在使用自動(dòng)de-ANSI-fication時(shí)，需要它。參見自動(dòng)de-ANSI-fication。

AM_GNU_GETTEXT

使用了GNU gettext的包需要使用本宏。（參見Gettext）。它將與gettext一起發(fā)布。如果Automake看到這個(gè)宏，Automake將確認(rèn)包是否符合gettext的某些要求。

AM_MAINTAINER_MODE

該宏為configure添加一個(gè)`--enable-maintainer-mode' 選項(xiàng)。如果使用了本宏，automake將關(guān)閉在生成的 `Makefile.in'中缺省的“maintainer-only”規(guī)則。在`Gnits'模式中，不允許使用本宏。（參見--gnu和--gnits的效果）。

AC_SUBST

AC_CHECK_TOOL

AC_CHECK_PROG

AC_CHECK_PROGS

AC_PATH_PROG

AC_PATH_PROGS

上述任意一個(gè)宏的第一個(gè)參數(shù)將在每個(gè)生成的`Makefile.in' 中自動(dòng)地被定義為一個(gè)變量。

自動(dòng)生成aclocal.m4

Automake包含了許多可以你的包中使用的的Autoconf宏；其中一些實(shí)際上是 Automake在某些情況下需要的。你必須在你的`aclocal.m4'中定義這些宏；否則autoconf將不能找到它們。

程序aclocal將基于`configure.in'的內(nèi)容自動(dòng)生成文件 `aclocal.m4'。它提供了一個(gè)不必四處尋找而獲得Automake提供的宏的便利方式。此外，aclocal機(jī)制對使用它的其它包來說，是可以擴(kuò)展的。

在啟動(dòng)時(shí)，aclocal掃描所有它能夠找到的`.m4'文件，以尋找宏定義。而后它掃描`configure.in'。任何在第一步中提到的宏，以及它所需要的宏，將被放到`aclocal.m4'中。

如果`acinclude.m4'存在，它的內(nèi)容將被自動(dòng)包含在 `aclocal.m4'中。這對于把本地宏合并到`configure'是有用的。

aclocal接受如下選項(xiàng)：

--acdir=dir

在目錄dir中，而不是在安裝目錄中，尋找宏文件。這通常用于調(diào)試。

--help

打印命令行選項(xiàng)的概述并且退出。

-I dir

把目錄dir添加到搜索`.m4'的目錄列表中。

--output=file

把輸出儲存到文件file中，而不是`aclocal.m4'中。

--print-ac-dir

打印aclocal將搜索`m4'文件的目錄名。當(dāng)給出本選項(xiàng)的時(shí)候，不實(shí)施通常的處理。包可以用本選項(xiàng)確定應(yīng)該把宏文件安裝到哪里。

--verbose

打印它所檢測的文件名。

--version

打印Automake的版本號并且退出。

由Automake支持的Autoconf宏

AM_CONFIG_HEADER

Automake將生成規(guī)則以自動(dòng)地重新生成config頭文件。如果你使用本宏，你必須在你的源代碼目錄中創(chuàng)建文件`stamp-h.in'。它可以為空。

AM_CYGWIN32

檢查本configure是否是在`Cygwin32'環(huán)境中運(yùn)行。（FIXME xref）。如果是，把輸出變量EXEEXT定義為 `.exe'；否則，把它定義為空字符串。Automake識別該宏并且用它生成在`Cygwin32'中可以自動(dòng)工作的`Makefile.in'。在`Cygwin32'環(huán)境中，即使在命令行中沒有明確指出，gcc 將生成文件名以`.exe'結(jié)尾的可執(zhí)行文件。Automake向 `Makefile.in'添加特定的代碼以適當(dāng)?shù)靥幚硭?

AM_FUNC_STRTOD

如果不能使用函數(shù)strtod，或者不能正確地工作（例如在SunOS 5.4上），就把`strtod.o'添加到輸出變量LIBOBJS中。

AM_FUNC_ERROR_AT_LINE

如果沒有找到error_at_line函數(shù)，就把`error.o'添加到LIBOBJS中。

AM_FUNC_MKTIME

檢查函數(shù)mktime。如果沒有找到，就把`mktime.o'添加到`LIBOBJS'中。

AM_FUNC_OBSTACK

檢查GNU obstacks代碼；如果沒有找到，就把`obstack.o'添加到`LIBOBJS'中。

AM_C_PROTOTYPES

檢查編譯器是否可以識別函數(shù)原型。如果可以識別，就定義`PROTOTYPES' 并且把輸出變量`U'和`ANSI2KNR'設(shè)置為空。否則，把`U'設(shè)置成`_'，并且把`ANSI2KNR' 設(shè)置成`./ansi2knr'。Automake使用這些值以實(shí)現(xiàn)自動(dòng)de-ANSI-fication。

AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL

如果使用TIOCGWINSZ需要`<sys/ioctl.h>'，那么定義GWINSZ_IN_SYS_IOCTL。否則，TIOCGWINSZ 可以在`<termios.h>'中發(fā)現(xiàn)。

AM_INIT_AUTOMAKE

運(yùn)行大部分`configure.in'需要的多個(gè)宏。本宏有兩個(gè)參數(shù)，包名稱和版本號。缺省情況下，本宏用AC_DEFINE定義`PACKAGE'和 `VERSION'。可以通過添加非空的第三個(gè)參數(shù)以避免這一行為。

AM_PATH_LISPDIR

搜索程序emacs，并且，如果找到了，把輸出變量lispdir 設(shè)置為到Emac的site-lisp目錄的完整路徑。

AM_PROG_CC_STDC

如果C編譯器的缺省狀態(tài)不是標(biāo)準(zhǔn)C（ANSI C），試圖把一個(gè)選項(xiàng)添加到輸出變量 CC中以使得C編譯器這樣做。本宏嘗試在各種系統(tǒng)中選擇標(biāo)準(zhǔn)C的各種選項(xiàng)。如果編譯器正確地處理函數(shù)原型，它就認(rèn)為編譯器處于標(biāo)準(zhǔn)C模式。 如果你使用本宏，你應(yīng)該在調(diào)用它之后檢查C編譯器是否被設(shè)置成接受標(biāo)準(zhǔn)C；如果不是，shell變量am_cv_prog_cc_stdc被設(shè)置成`no'。如果你按照標(biāo)準(zhǔn)C寫你的源代碼，你可以利用ansi2knr選項(xiàng)創(chuàng)建它的非標(biāo)準(zhǔn)C版本。

AM_PROG_INSTALL

類似與AC_PROG_INSTALL，但還定義了INSTALL_SCRIPT。

AM_PROG_LEX

類似與帶有AC_DECL_YYTEXT的AC_PROG_LEX，但在沒有l(wèi)ex的系統(tǒng)上使用腳本missing。 `HP-UX 10'是一個(gè)這樣的系統(tǒng)。

AM_SANITY_CHECK

它檢查并確保在創(chuàng)建目錄中被創(chuàng)建的文件比源代碼目錄中的文件要新。在時(shí)鐘設(shè)置不正確的系統(tǒng)中它可能失敗。本宏在AM_INIT_AUTOMAKE 中自動(dòng)運(yùn)行。

AM_SYS_POSIX_TERMIOS

檢查系統(tǒng)中，是否可以使用POSIX termios頭文件和函數(shù)。如果可以，就把shell變量 am_cv_sys_posix_termios設(shè)置為`yes'。如果不能使用，就把am_cv_sys_posix_termios設(shè)置為`no'。

AM_TYPE_PTRDIFF_T

如果類型`ptrdiff_t'是在`<stddef.h>'中定義的，就定義`HAVE_PTRDIFF_T'。

AM_WITH_DMALLOC

增加dmalloc包支持。如果用戶用`--with-dmalloc'進(jìn)行配置，那么定義WITH_DMALLOC并且把`-ldmalloc'添加到LIBS。包dmalloc可以在ftp://ftp.letters.com/src/dmalloc/dmalloc.tar.gz 找到。

AM_WITH_REGEX

把`--with-regex'添加到configure的命令行中。如果給出`--with-regex'（缺省設(shè)置），那么使用 `regex'常規(guī)表達(dá)式庫，`regex.o' 被添加到`LIBOBJS'中，并且定義`WITH_REGEX'。如果給出`--without-regex'，那么使用`rx' 常規(guī)表達(dá)式庫，`rx.o'被添加到`LIBOBJS'中。

編寫你自己的aclocal宏

aclocal不含有任何宏的任何內(nèi)置信息，所以擴(kuò)展你自己的宏是十分容易的。

它通常被用于那些需要為使用它的其它程序提供它們自己的Autoconf宏的庫。例如gettext庫支持宏 AM_GNU_GETTEXT，該宏將被任何使用gettext的任何包所使用。在安裝庫的時(shí)候，它安裝宏以便aclocal可以找到它。

一個(gè)宏文件應(yīng)該是一系列AC_DEFUN'。aclocal還懂得AC_REQUIRE，所以把每個(gè)宏儲存在一個(gè)單獨(dú)的文件中是安全的。

一個(gè)宏文件的文件名應(yīng)該以`.m4'結(jié)尾。這類文件都應(yīng)該安裝在`$(datadir)/aclocal'中。

頂層`Makefile.am'

在非平（non-flat）包中，頂層`Makefile.am'必須告訴Automake 應(yīng)該在那個(gè)子目錄中進(jìn)行創(chuàng)建。這通過變量SUBDIRS來完成。

宏SUBDIRS保存了需要進(jìn)行各種創(chuàng)建的子目錄列表。在生成的`Makefile'中的許多目標(biāo)（例如，all）即需要在本目錄下運(yùn)行，也需要在所有特定的子目錄下運(yùn)行。需要指出，出現(xiàn)在 SUBDIRS中的子目錄并不一定含有`Makefile.am' ；只要在配置（運(yùn)行configuration）之后含有`Makefile'就行了。這使得你可以從不使用Automake的軟件包（例如，gettext）中引入庫。在SUBDIRS中提到的目錄必須是當(dāng)前目錄的直接子目錄。例如，你可以把`src/subdir'添加到SUBDIRS中。

在一個(gè)深（deep）包中，頂層`Makefile.am'通常十分簡短。例如，下面是Hello發(fā)布版中的`Makefile.am'：

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

就像在GNU Inetutils中的情況一樣，如果你只需要?jiǎng)?chuàng)建整個(gè)包的一個(gè)子集，你可以覆蓋變量SUBDIRS。在你的 `Makefile.am'中包含：

SUBDIRS = @SUBDIRS@

而后在你的`configure.in'中，你可以指明：

SUBDIRS = "src doc lib po"
AC_SUBST(SUBDIRS)

以上修改的結(jié)果是：automake將創(chuàng)建包以獲得subdirs，但實(shí)際上在運(yùn)行configure之前并沒有把目錄列表包括進(jìn)來。

SUBDIRS可以包含配置替換（例如，`@DIRS@'）； Automake本身并不實(shí)際檢查這個(gè)變量的內(nèi)容。

如果定義了SUBDIRS，那么你的`configure.in' 必須包含AC_PROG_MAKE_SET。

對SUBDIRS的使用并不限于頂層目錄中的`Makefile.am'。 Automake可以用于構(gòu)造任意深度的包。

創(chuàng)建程序和庫

Automake的大部分功能的目的是使創(chuàng)建C程序和庫變得容易些。

創(chuàng)建一個(gè)程序

在一個(gè)含有將被創(chuàng)建成一個(gè)程序（而不是創(chuàng)建成一個(gè)庫）的源代碼的目錄中，要使用主變量`PROGRAMS'。程序可以安裝到`bindir'、 `sbindir'、`libexecdir'、`pkglibdir'中，或者根本不安裝（`noinst'）。

例如：

bin_PROGRAMS = hello

在這種簡單的情況下，最終的`Makefile.in'將含有代碼以生成名為hello的一個(gè)程序。變量hello_SOURCES 用于確定哪些源代碼應(yīng)該被創(chuàng)建到可執(zhí)行文件中去：

hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h

它將導(dǎo)致所有提及的`.c'文件被編譯成對應(yīng)的`.o' 文件。而后被一同連接以生成`hello'。

如果需要`prog_SOURCES'，但并未定義它，那么它被缺省地設(shè)置成單個(gè)文件`prog.c'。在上面的例子中，對hello_SOURCES 的定義實(shí)際上是多余的。

可以把多個(gè)程序創(chuàng)建到一個(gè)目錄中。多個(gè)程序可以共享一個(gè)源代碼文件。源代碼文件必須在需要它的每個(gè)`_SOURCES'中列出。

出現(xiàn)在`_SOURCES'中的頭文件將被包含在發(fā)布版本中，其它的頭文件將被忽略。因?yàn)樗⒉幻黠@，你不應(yīng)該把由`configure'生成的頭文件包含在變量`_SOURCES'中；不應(yīng)該發(fā)布這個(gè)文件。也可以列出lex（`.l'）和yacc（`.y'）文件；參見對Yacc和Lex的支持。

即使不是所有的文件在所有的情況下都需要被創(chuàng)建，Automake也必須知道所有可能被連接到程序中的源文件。所有僅僅是可能被創(chuàng)建的文件應(yīng)該被適當(dāng)?shù)靥砑拥阶兞?samp>`EXTRA_'中。例如，如果`hello-linux.c' 是有條件地被包含在hello中，`Makefile.am'應(yīng)該包括：

EXTRA_hello_SOURCES = hello-linux.c

類似地，有時(shí)候需要在配置的時(shí)刻確定創(chuàng)建那些程序。例如GNU cpio 僅僅在特殊情況下才創(chuàng)建mt和rmt。

在這種情況下，你必須把可能創(chuàng)建的所有程序都告訴automake，但同時(shí)使生成的`Makefile.in'使用由configure 指明的程序。這可以通過在EXTRA_PROGRAMS中列出所有可能創(chuàng)建的程序的同時(shí)，把configure提供的值的替換到每個(gè)`_PROGRAMS'變量的定義中，來完成。

如果你需要和configure沒有找到的庫相連接，你可以使用LDADD來完成。該變量實(shí)際上可以用于把任何選項(xiàng)添加到連接器的命令行中。

有時(shí)，要在一個(gè)目錄中創(chuàng)建多個(gè)程序，但并不共享相同的連接時(shí)刻需求（link-time requirement）。在這種情況下，你可以使用變量`prog_LDADD' （其中prog是出現(xiàn)在某些`_PROGRAMS'變量中的程序名）來覆蓋全局的LDADD。（對于某個(gè)程序來說，如果存在這個(gè)變量，那么那個(gè)程序的連接就不使用LDADD。）

例如，在GNU cpio中，pax、cpio和mt 需要和庫`libcpio.a'連接。然而，rmt在同一個(gè)目錄中創(chuàng)建，并且不需要與`libcpio.a'連接。此外，mt 和rmt也僅僅在這種結(jié)構(gòu)下創(chuàng)建。這里是cpio的`src/Makefile.am' 內(nèi)容（有刪節(jié)）：

bin_PROGRAMS = cpio pax @MT@
libexec_PROGRAMS = @RMT@
EXTRA_PROGRAMS = mt rmt
LDADD = ../lib/libcpio.a @INTLLIBS@
rmt_LDADD =
cpio_SOURCES = ...
pax_SOURCES = ...
mt_SOURCES = ...
rmt_SOURCES = ...

變量`prog_LDADD'并不適用與傳遞程序特定的連接器選項(xiàng)（除了`-l'和`-L'之外）。所以，為此請使用變量`prog_LDFLAGS'。

有時(shí)候，是否創(chuàng)建一個(gè)程序依賴于不屬于那個(gè)程序的某些其它目標(biāo)。通過使用變量`prog_DEPENDENCIES'可以實(shí)現(xiàn)該功能。每個(gè)程序都依賴于這個(gè)變量的內(nèi)容，但是不對它進(jìn)行進(jìn)一步的解釋。

如果沒有給出`prog_DEPENDENCIES'，它就由Automake來計(jì)算。自動(dòng)獲取的值是進(jìn)行了大部分配置替換后的`prog_LDADD'內(nèi)容，即刪除了`-l'和`-L'選項(xiàng)。沒有進(jìn)行的配置替換僅僅是 `@LIBOBJS@' and `@ALLOCA@'；沒有進(jìn)行這些替換是因?yàn)樗鼈儾粫?huì)使生成的`prog_DEPENDENCIES'含有非法的值。

創(chuàng)建一個(gè)庫

創(chuàng)建庫與創(chuàng)建程序十分類似。在這種情況下，主變量的名字是`LIBRARIES'。庫可以安裝到libdir或pkglibdir之中。

關(guān)于如何使用Libtool和主變量`LTLIBRARIES'創(chuàng)建共享庫的詳情，請參見創(chuàng)建共享庫。

每個(gè)`_LIBRARIES'變量都是需要被創(chuàng)建的庫的列表。例如創(chuàng)建一個(gè)名為`libcpio.a'的庫，但并不安裝它，你可以寫：

noinst_LIBRARIES = libcpio.a

確定那些源代碼應(yīng)該被創(chuàng)建到庫中的方式與創(chuàng)建程序的情況完全相同，是通過變量`_SOURCES'。需要指出的是，庫的名字是規(guī)范化的（參見派生變量是如何命名的），所以對應(yīng)與`liblob.a'的`_SOURCES'變量對應(yīng)的變量名為`liblob_a_SOURCES'，而不是`liblob.a_SOURCES'。

通過使用變量`library_LIBADD'，可以把額外的對象添加到庫中。這應(yīng)該由configure確定的對象使用。再看看cpio：

libcpio_a_LIBADD = @LIBOBJS@ @ALLOCA@

對LIBOBJS和ALLOCA的特別處理

Automake顯式地識別對@LIBOBJS@和@ALLOCA@的使用，并用該信息，以及從 `configure.in'中派生出的LIBOBJS文件列表，把適當(dāng)?shù)脑次募詣?dòng)添加到發(fā)布版本中。（參見需要發(fā)布哪些文件）。這些源文件還按照依賴跟蹤機(jī)制進(jìn)行自動(dòng)處理，參見自動(dòng)依賴跟蹤。

在任何`_LDADD'或`_LIBADD'變量中， @LIBOBJS@和@ALLOCA@都將被自動(dòng)識別出來。

創(chuàng)建一個(gè)共享庫

創(chuàng)建共享庫是一件相對復(fù)雜的事情。為此，提供了GNU Libtool以使我們可以按照與平臺無關(guān)的方式創(chuàng)建共享庫（參見Libtool手冊）。

Automake使用Libtool來創(chuàng)建在主變量`LTLIBRARIES'中聲明的庫。每個(gè)`_LTLIBRARIES'變量都是一個(gè)需要?jiǎng)?chuàng)建的共享庫的列表。例如，為了創(chuàng)建一個(gè)名為`libgettext.a'的庫和它對應(yīng)的共享庫，并且把它安裝到`libdir'，可以寫：

lib_LTLIBRARIES = libgettext.la

需要指出的是：共享庫必須被安裝，所以不允許使用 `noinst_LTLIBRARIES'和`check_LTLIBRARIES'。

對于每個(gè)庫，變量`library_LIBADD'包含了需要被添加到共享庫中的額外的libtool對象（`.lo'文件）。變量`library_LDFLAGS'包含了所有附加的libtool選項(xiàng)，例如`-version-info'或者`-static'。

普通的庫可能需要使用@LIBOBJS@，而libtool庫必須是使用 @LTLIBOBJS@。必須這樣做是因?yàn)閘ibtool所操作的目標(biāo)文件并不僅僅是`.o'。libtool手冊包含了關(guān)于這個(gè)問題的細(xì)節(jié)。

對于安裝在某些目錄中的庫，automake將自動(dòng)提供適當(dāng)?shù)?`-rpath'選項(xiàng)。然而，對于那些在配置時(shí)刻才能都確定的庫（因而必須在EXTRA_LTLIBRARIES中給出），automake 并不知道它們最終安裝的目錄；對于這類庫，你必須把 `-rpath'選項(xiàng)手工地添加到適當(dāng)?shù)?samp>`_LDFLAGS' 變量中去。

詳情請參見Libtool手冊。

創(chuàng)建一個(gè)程序時(shí)使用的變量

有時(shí)有必要知道那個(gè)`Makefile'變量被Automake用于編譯；例如在某些特殊情況下，你可能需要完成你自己的編譯任務(wù)。

有些變量是從Autoconf中繼承而來的；它們是CC、 CFLAGS、CPPFLAGS、DEFS、 LDFLAGS和LIBS。

還有一些附加的變量是Automake自行定義的：

INCLUDES

一個(gè)`-I'選項(xiàng)的列表。如果你需要包含特殊的目錄，你可以在你的`Makefile.am'中設(shè)置它。 automake已經(jīng)自動(dòng)地提供了一些`-I'選項(xiàng)。特別地，它生成`-I$(srcdir)'和一個(gè)指向保存了 `config.h'的目錄的`-I'選項(xiàng)（如果你已經(jīng)使用了AC_CONFIG_HEADER或者AM_CONFIG_HEADER）。 除了`-I'以外，INCLUDES實(shí)際上還可以用于添加任何cpp選項(xiàng)。例如，有時(shí)用它把任意的`-D'選項(xiàng)傳遞給編譯器。

COMPILE

實(shí)際用于編譯C源文件的命令。文件名被添加到它的后面以形成完整的命令行。

LINK

實(shí)際用于連接C程序的命令。

對Yacc和Lex的支持

Automake對Yacc和Lex有一些特殊的支持。

Automake假定由yacc（或lex）生成的`.c'文件是以輸入文件名為基礎(chǔ)命名的。就是說，對于yacc源文件`foo.y'， automake將認(rèn)為生成的中間文件是`foo.c'（而不是更加傳統(tǒng)的 `y.tab.c'）。

yacc源文件的擴(kuò)展名被用于確定生成的`C'或`C++' 文件的擴(kuò)展名。使用擴(kuò)展名`.y'的文件將被轉(zhuǎn)化成 `.c'文件；類似地，擴(kuò)展名`.yy'轉(zhuǎn)化成 `.cc'；`.y++'轉(zhuǎn)化成`c++'； `.yxx'轉(zhuǎn)化成`.cxx'；類似地，Lex源文件可以用于生成`C'或者`C++'；擴(kuò)展名 `.l'、`.ll'、`.l++'和 `.lxx'都可以被識別。

你不應(yīng)該在任何`SOURCES'變量中明確地提及中間的（`C'或者`C++'）文件；只要列出源文件就可以了。

由yacc（或lex）生成的中間文件將被包含在由它創(chuàng)建的任何發(fā)布版本中。這樣用戶就不需要擁有yacc或lex了。

如果出現(xiàn)了yacc源文件，那么你的`configure.in'必須定義變量`YACC'。完成這個(gè)任務(wù)最容易的方式是使用宏`AC_PROG_YACC'。

相似地，如果出現(xiàn)了lex源文件，那么你的`configure.in' 必須定義變量`LEX'。你可以用宏`AC_PROG_LEX' 來完成這個(gè)工作。Automake對lex的支持還要求你使用宏 `AC_DECL_YYTEXT'--automake需要知道 `LEX_OUTPUT_ROOT'的值。

Automake允許在一個(gè)程序中使用多個(gè)yacc （或lex）源文件。 Automake使用一個(gè)稱為ylwrap的小程序在子目錄中運(yùn)行 yacc（或者lex）。必須這樣做是因?yàn)?yacc的輸出文件名被修改了，并且并行的make可以同時(shí)地處理多于一個(gè)的yacc實(shí)例。ylwrap和automake一同發(fā)布。它應(yīng)該出現(xiàn)在由`AC_CONFIG_AUX_DIR'給出的目錄，如果沒有在`configure.in'中給出這個(gè)宏，它就應(yīng)該出現(xiàn)在當(dāng)前目錄中。

對于yacc，僅僅管理鎖是不夠的。yacc的輸出還總是在內(nèi)部使用相同的符號名，所以不可能把兩個(gè)yacc解析器（parser）連接到同一個(gè)可執(zhí)行文件中。

我們建議使用如下在gdb中應(yīng)用的改名方式：

#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

對于每一個(gè)define，用任何你喜歡的東西替換前綴`c_'。這些定義可以為bison、byacc和傳統(tǒng)的 yacc工作。如果你發(fā)現(xiàn)某個(gè)解析器使用了這里所沒有提到的符號，請告訴我們以便把它添加到上述列表中。

C++和其它語言

Automake對C++提供了完整的支持，對其它語言也有一些不完善的支持。對其它語言的支持將根據(jù)實(shí)際需要被添加進(jìn)來。

任何包括了C++代碼的包都必須在`configure.in'中定義輸出變量`CXX'；完成這一任務(wù)的最簡單方式就是使用宏AC_PROG_CXX。

在出現(xiàn)C++源文件的時(shí)候需要定義幾個(gè)附加的變量：

CXX

C++編譯器的名稱。

CXXFLAGS

傳遞給C++編譯器的任何選項(xiàng)。

CXXCOMPILE

實(shí)際用于編譯C++源文件的命令。文件名將被添加到它的后面以構(gòu)成完整的命令行。

CXXLINK

實(shí)際用于連接C++程序的命令。

自動(dòng)de-ANSI-fication

雖然GNU標(biāo)準(zhǔn)允許使用標(biāo)準(zhǔn)C，使用標(biāo)準(zhǔn)C可能使包難以移植到一些舊的編譯器上（典型的是SunOS）。

在實(shí)際的編譯發(fā)生之前，Automake允許你通過對每個(gè)源文件實(shí)施"de-ANSI-fying" 以在這一類機(jī)器上進(jìn)行工作。

如果`Makefile.am'變量AUTOMAKE_OPTIONS （參見改變Automake的行為）包括了選項(xiàng)ansi2knr， 那么處理de-ANSI-fication的代碼就被插入到生成的`Makefile.in'中。

這使得目錄中的每個(gè)C源文件都被看作標(biāo)準(zhǔn)C。如果有標(biāo)準(zhǔn)C編譯器可以使用，就使用它。如果沒有標(biāo)準(zhǔn)C編譯器可用，就用程序ansi2knr 把文件轉(zhuǎn)換成K&R C，而后再被編譯。

程序ansi2knr相當(dāng)簡單。它假定源代碼按照特定的方式進(jìn)行排版；詳情請參見ansi2knr的man。

支持de-ANSI-fication需要把源文件`ansi2knr.c'和 `ansi2knr.1'與標(biāo)準(zhǔn)C源代碼放在同一個(gè)包中；這些文件與Automake 一同發(fā)布。此外，包的`configure.in'必須調(diào)用宏AM_C_PROTOTYPES。

Automake還負(fù)責(zé)在當(dāng)前包的其它目錄中尋找ansi2knr的支持文件。這通過把到達(dá)適當(dāng)目錄的相對路徑添加到選項(xiàng)ansi2knr之前來完成。例如，假定一個(gè)包的標(biāo)準(zhǔn)C代碼儲存在子目錄`src'和`lib'中。文件`ansi2knr.c'和`ansi2knr.1'出現(xiàn)在`lib'中。那么下述內(nèi)容應(yīng)該在`src/Makefile.am'中出現(xiàn)：

AUTOMAKE_OPTIONS = ../lib/ansi2knr

如果沒有給出前綴，就假定文件在當(dāng)前目錄中。

自動(dòng)依賴性跟蹤

作為開發(fā)者，經(jīng)常痛苦地在每次項(xiàng)目的include文件的依賴關(guān)系發(fā)生變化的時(shí)候?qū)?tt>`Makefile.in'進(jìn)行更新。 automake提供了一種方式以自動(dòng)跟蹤依賴關(guān)系的變化，并且在生成的`Makefile.in'中給出這些依賴關(guān)系。

當(dāng)前這種支持需要使用GNU make和gcc。如果有足夠的必要性，將來可能提供對不同的依賴性生成程序的支持。在此之前，如果當(dāng)前目錄中定義了任何C程序或者庫，在缺省狀態(tài)下就啟動(dòng)這種模式，因而你可能從非GNU make那里得到一個(gè)`Must be a separator'錯(cuò)誤。

當(dāng)你決定創(chuàng)建一個(gè)發(fā)布版本時(shí)，目標(biāo)dist 將用`--include-deps'和其它選項(xiàng)重新運(yùn)行automake。這將是的以前生成的依賴關(guān)系被插入到生成的`Makefile.in'中，并因而被插入到發(fā)布之中。這一步驟還不會(huì)把依賴性生成代碼包括進(jìn)來，所以那些下載你的發(fā)布版本的人就不必使用GNU make和gcc，而且不會(huì)導(dǎo)致錯(cuò)誤。

在添加到`Makefile.in'的時(shí)候，所有系統(tǒng)特定的依賴性都被自動(dòng)刪除了。這可以通過把文件羅列在變量`OMIT_DEPENDENCIES' 中來實(shí)現(xiàn)。例如：automake將刪除所有對系統(tǒng)頭文件的引用。有時(shí)有必要指明應(yīng)該刪除哪個(gè)頭文件。例如，如果你的 `configure.in'使用了`AM_WITH_REGEX'，那么就應(yīng)該刪除任何與`rx.h'或者 `regex.h'有關(guān)的依賴性，這是因?yàn)樵谟脩襞渲冒斑€不知道應(yīng)該使用那個(gè)頭文件。

實(shí)際上，automake足夠地聰明以至于可以處理諸如常規(guī)表達(dá)式頭文件的特殊情況。如果使用了`AM_GNU_GETTEXT'，它還將自動(dòng)忽略 `libintl.h'。

自動(dòng)依賴性跟蹤功能可以通過在變量AUTOMAKE_OPTIONS 中設(shè)置no-dependencies來關(guān)閉。

如果你打開由make dist創(chuàng)建的發(fā)布版本，而且你希望重新添加依賴性跟蹤的代碼，只要重新運(yùn)行automake就行了。

實(shí)際的依賴性文件被儲存在創(chuàng)建目錄下的一個(gè)名為`.deps' 的子目錄中。這些依賴性是機(jī)器特有的。如果你愿意，刪除它們是安全的；它們將在下次創(chuàng)建的時(shí)候自動(dòng)重建。

其它派生對象

Automake可以處理不是C程序的其它派生對象。有時(shí)對實(shí)際創(chuàng)建這類對象的支持必須顯式地給出，但Automake仍然會(huì)自動(dòng)地處理安裝和發(fā)布。

可執(zhí)行腳本

定義和安裝腳本程序是可能的。這種程序被羅列在主變量`SCRIPTS'中。 automake沒有為腳本定義任何依賴性關(guān)系； `Makefile.am'應(yīng)該包含正確的規(guī)則。

automake并不假定腳本是派生的對象；這些對象必須被手工地刪除；詳情請參見清除了些什么。

automake本身就是在配置時(shí)刻從`automake.in' 中生成的腳本。下面給出了如何處理它：

bin_SCRIPTS = automake

因?yàn)?code>automake出現(xiàn)在宏AC_OUTPUT中，自動(dòng)地生成了一個(gè)關(guān)于它的目標(biāo)。

腳本對象可以安裝在bindir、sbindir、 libexecdir或者pkgdatadir中。

頭文件

頭文件由`HEADERS'變量族所指定。通常是不安裝頭文件的，所以變量noinst_HEADERS是最常用的。

所有的頭文件都必須在某些地方列出；沒有列出的頭文件將不會(huì)出現(xiàn)在發(fā)布版本中。通常最清楚的方式是和程序的其它源代碼一起列出不會(huì)被安裝的頭文件。參見創(chuàng)建一個(gè)程序。在變量`_SOURCES'中列出的頭文件不需要在任何 `_HEADERS'變量中再次列出。

頭文件可以安裝到includedir、oldincludedir或者 pkgincludedir中。

與體系結(jié)構(gòu)無關(guān)的數(shù)據(jù)文件

Automake使用`DATA'族變量來支持對各種數(shù)據(jù)文件的安裝。

這些數(shù)據(jù)可以安裝在目錄datadir、 sysconfdir、sharedstatedir、 localstatedir或者pkgdatadir中。

在缺省狀態(tài)下，數(shù)據(jù)文件不會(huì)被包含在發(fā)布版本中。

下面是automake如何安裝它的附加數(shù)據(jù)文件：

pkgdata_DATA = clean-kr.am clean.am ...

已創(chuàng)建的源代碼

有時(shí)候，一個(gè)可以被稱作“源文件”的文件（例如一個(gè)C `.h'文件）實(shí)際上是從其它文件中派生出來的。這類文件應(yīng)該被羅列在變量 BUILT_SOURCES中。

在缺省狀態(tài)下，不會(huì)編譯已創(chuàng)建的源文件。你必須在一些其它的`_SOURCES'變量中明確地給出它們，以便對其進(jìn)行編譯。

需要說明的是，在某些情況下，BUILT_SOURCES將以令人驚訝的方式工作。為了獲得已創(chuàng)建的源文件以進(jìn)行自動(dòng)依賴性跟蹤，`Makefile'必須依賴于 $(BUILT_SOURCES)。這導(dǎo)致這些源文件可能在某些可笑的時(shí)候被重新創(chuàng)建。

其它的GNU工具

因?yàn)锳utomake被設(shè)計(jì)成為GNU程序自動(dòng)生成`Makefile.in'，它為與其它GNU工具進(jìn)行互操作做出了努力。

Emacs Lisp

Automake為Emacs Lisp提供了一些支持。主變量`LISP'被用于保存一個(gè)`.el'文件的列表。該主變量的可能前綴有：`lisp_' 和`noinst_'。如果定義了lisp_LISP，那么 `configure.in'就必須運(yùn)行AM_PATH_LISPDIR （參見Automake支持的Autoconf宏）.

在缺省狀態(tài)下，Automake將使用通過AM_PATH_LISPDIR 找到的Emacs按字節(jié)編譯（byte-compile）所有Emacs Lisp源文件。如果你不希望使用字節(jié)編譯，請把變量`ELCFILES'定義為空。 字節(jié)編譯的Emacs Lisp文件并不能在所有版本的Emacs間移植，所以如果你希望在同一個(gè)地方安裝多于一個(gè)版本的Emacs，你可以關(guān)閉它。進(jìn)一步，許多包并沒有從字節(jié)編譯中獲得實(shí)際的好處。我們?nèi)匀唤ㄗh你不要改變?nèi)笔≡O(shè)置。對站點(diǎn)進(jìn)行特殊的配置以適用于它們自身，可能比為其它所有人創(chuàng)建不和諧的安裝要更好一些。

Gettext

如果在`configure.in'中出現(xiàn)了AM_GNU_GETTEXT，那么Automake就開啟對GNU gettext的支持，一個(gè)支持國際化的消息編目系統(tǒng)（參見GNU gettext工具中的`GNU Gettext'節(jié)）。

在Automake中對gettext的支持需要把兩個(gè)子目錄附加到包中，`intl'和`po'。Automake確認(rèn)這些目錄的存在并且在SUBDIRS中被給出。

更進(jìn)一步，Automake檢查在`configure.in'中包含了與所有合法的`.po'文件相對應(yīng)的`ALL_LINGUAS'定義，并且沒有多余的定義。

Guile

Automake為構(gòu)造Guile模塊提供了一些自動(dòng)支持。如果宏AM_INIT_GUILE_MODULE 出現(xiàn)在`configure.in'中，Automake將開啟對Guile的支持。

現(xiàn)在對Guile的支持僅僅表示宏AM_INIT_GUILE_MODULE：

• 運(yùn)行了AM_INIT_AUTOMAKE。
• 帶路徑`..'運(yùn)行了AC_CONFIG_AUX_DIR。

隨著Guile模塊代碼的成熟，無疑Automake的支持也將會(huì)更好。

Libtool

Automake通過主變量`LTLIBRARIES'提供了對GNU Libtool的支持（參見Libtool手冊）參見創(chuàng)建一個(gè)共享庫。

Java

通過主變量`JAVA'，Automake為Java的編譯提供了少量支持。

任何在變量`_JAVA'列舉的`.java'文件在創(chuàng)建時(shí)刻將用JAVAC進(jìn)行編譯。在缺省狀態(tài)，`.class'文件不會(huì)被包含在發(fā)布版本中。

目前Automake正試圖限制只能在`Makefile.am'中使用一個(gè)`_JAVA'主變量。引入這個(gè)限制是因?yàn)椋ǔＪ遣豢赡苤滥膫€(gè)`.class'文件是從哪個(gè)`.java' 文件中生成的 -- 因此不可能知道哪個(gè)文件應(yīng)該被安裝到哪里。

創(chuàng)建文檔

目前Automake提供了對Texinfo和man的支持。

Texinfo

如果當(dāng)前目錄中含有Texinfo源文件，你必須在主變量`TEXINFOS' 中給出聲明。通常Texinfo文件被轉(zhuǎn)換成info，因此經(jīng)常在這里使用宏info_TEXINFOS。需要指出的是任何Texinfo源文件的文件名的擴(kuò)展名都必須是`.texi'或者`.texinfo'。

如果`.texi'文件@includes `version.texi'，就將自動(dòng)生成那個(gè)文件。 `version.texi'定義了三個(gè)你可以引用的Texinfo宏：EDITION、VERSION和 UPDATED。前兩個(gè)宏保存了你的包的版本號（為清晰起見而分別保存）；最后一個(gè)宏是最后一次修改主文件的日期。對`version.texi'的支持需要程序mdate-sh；這個(gè)程序由Automake提供。

有時(shí)，一個(gè)info文件實(shí)際上依賴于多個(gè)`.texi'文件。例如，在GNU Hello中，`hello.texi'包括了文件`gpl.texi'。你可以通過使用變量`texi_TEXINFOS'告訴Automake 這一依賴性。下面就是Hello處理它的代碼：

info_TEXINFOS = hello.texi
hello_TEXINFOS = gpl.texi

在缺省狀態(tài)下，Automake認(rèn)為`texinfo.tex'出現(xiàn)在Texinfo源文件所在的目錄中。然而，如果你在`configure.in'中使用了AC_CONFIG_AUX_DIR 那么將到那個(gè)目錄中去尋找`texinfo.tex'文件。如果給出了 `--add-missing'，Automake將自動(dòng)提供`texinfo.tex'

如果你的包在許多目錄中儲存了Texinfo文件，你可以用變量TEXINFO_TEX 來告訴automake到那里去尋找你的包的規(guī)范`texinfo.tex'文件。這個(gè)變量的值應(yīng)該是從當(dāng)前`Makefile.am'到`texinfo.tex' 的相對路徑。

TEXINFO_TEX = ../doc/texinfo.tex

選項(xiàng)`no-texinfo.tex'可以消除對`texinfo.tex'的需要。但使用變量TEXINFO_TEX更好些，因?yàn)樗沟媚繕?biāo)dvi 仍然可以工作。

Automake生成一個(gè)install-info目標(biāo)；一些人顯式地使用它。在缺省狀態(tài)下，info文檔通過運(yùn)行`make install'來安裝。可以通過給出選項(xiàng)no-installinfo以阻止執(zhí)行這一操作。

Man手冊

一個(gè)包還可以包含man手冊。（參見GNU關(guān)于此事的標(biāo)準(zhǔn)，GNU編碼標(biāo)準(zhǔn)中的`Man手冊'節(jié)。）用主變量`MANS'聲明Man手冊。通常使用宏man_MANS。根據(jù)文件的擴(kuò)展名，Man手冊被自動(dòng)地安裝到mandir的正確子目錄中。

在缺省狀態(tài)下，man手冊通過運(yùn)行`make install'安裝。然而，因?yàn)镚NU項(xiàng)目并不需要man手冊，許多維護(hù)者沒有花費(fèi)時(shí)間以及時(shí)更新man手冊。在這些情況下，給出選項(xiàng)no-installman 將阻止對man手冊的安裝。用戶仍然可以顯式地使用`make install-man' 來安裝它們。

下面是GNU cpio如何處理它的文檔（它同時(shí)包括了Texinfo文檔和 man手冊）：

info_TEXINFOS = cpio.texi
man_MANS = cpio.1 mt.1

Texinfo源文件和info文檔都被看作用于創(chuàng)建發(fā)布版本的源代碼。

Man手冊現(xiàn)在并不被看作源代碼，因?yàn)閙an手冊有時(shí)是自動(dòng)生成的。

安裝了些什么

自然地，一旦你的程序被創(chuàng)建了，Automake實(shí)際上處理了安裝程序的細(xì)節(jié)。所有PROGRAMS、SCRIPTS、 LIBRARIES、LISP、DATA 和HEADERS中列出的文件都被自動(dòng)地安裝在適當(dāng)?shù)奈恢谩?

Automake還可以處理對info文檔和man手冊的安裝。

Automake生成分離的install-data和install-exec目標(biāo)，如果安裝器（installer）在共享的目錄結(jié)構(gòu)中為多個(gè)機(jī)器進(jìn)行安裝，這些目標(biāo)允許與機(jī)器獨(dú)立的部分僅僅被安裝一次。目標(biāo)install依賴于這兩個(gè)目標(biāo)。

Automake還生成一個(gè)uninstall目標(biāo)，一個(gè) installdirs目標(biāo)，和一個(gè)install-strip目標(biāo)。

通過定義目標(biāo)install-exec-local，或者目標(biāo)install-data-local 就可以擴(kuò)展這一機(jī)制。如果這些目標(biāo)存在，它們將在運(yùn)行`make install'時(shí)運(yùn)行。

使用標(biāo)準(zhǔn)目錄前綴`data'、`info'、`man'、 `include'、`oldinclude'、`pkgdata'或者 `pkginclude'的變量（例如，`data_DATA'）將由 `install-data'安裝。

使用標(biāo)準(zhǔn)目錄前綴`bin'、`sbin'、`libexec'、 `sysconf'、`localstate'、`lib'或者 `pkglib'的變量（例如，`bin_PROGRAMS'）將由 `install-exec'安裝。

任何使用了含有`exec'的用戶定義目錄前綴的變量（例如，`myexecbin_PROGRAMS'）將由`install-exec'安裝。所有使用其它用戶定義的前綴的變量將由`install-data'安裝。

Automake在所有的install規(guī)則中生成對變量`DESTDIR'的支持；參見GNU編碼標(biāo)準(zhǔn)中的`Makefile慣例'節(jié)。

清除了些什么

GNU Makefile標(biāo)準(zhǔn)給出了許多不同的清除規(guī)則。通常由Automake自動(dòng)確定可以清除哪些文件。當(dāng)然，Automake還能識別一些為指明需要額外地清除的文件而定義的變量。這些變量是 MOSTLYCLEANFILES、CLEANFILES、DISTCLEANFILES 和MAINTAINERCLEANFILES。

需要發(fā)布哪些文件

生成的`Makefile.in'中的dist目標(biāo)可以用于產(chǎn)生用gzip壓縮了的發(fā)布tar文件。 tar文件是根據(jù)`PACKAGE'變量和`VERSION'變量命名的；精確地說，被命名為`package-version.tar.gz'。

在大部分情況下，發(fā)布版本中的文件由Automake自動(dòng)尋找：所有的源文件被自動(dòng)地包含在發(fā)布版本中，還有所有的 `Makefile.am'和`Makefile.in'。Automake定義了一些常用的內(nèi)置文件，如果出現(xiàn)在當(dāng)前目錄中，那么就被自動(dòng)地包含在發(fā)布版本中。可以用`automake --help'打印它們。此外，由configure 讀入的文件（例如，對應(yīng)于由AC_OUTPUT調(diào)用指明的文件的源文件）將被自動(dòng)地包含在發(fā)布版本中。

有時(shí)，除此而外仍然有一些文件需要被發(fā)布而沒有包含在自動(dòng)規(guī)則之中。這些文件應(yīng)該在變量EXTRA_DIST中列出。需要指出的是，EXTRA_DIST只能處理當(dāng)前目錄中的文件；其它目錄中的文件將使make dist在運(yùn)行時(shí)發(fā)生錯(cuò)誤。

如果你定義了SUBDIRS，automake將遞歸地把子目錄包含在發(fā)布版本中。如果是有條件地定義SUBDIRS（參見條件），通常automake將把所有可能出現(xiàn)在SUBDIRS中的所有目錄包含在發(fā)布版本中。如果你需要有條件地給出一組目錄，你可以設(shè)置變量DIST_SUBDIRS以精確地列出需要包含在發(fā)布版本中的子目錄。

有時(shí)在發(fā)布版本打包之前修改發(fā)布版本是有用的。如果目標(biāo)dist-hook存在，它可以在填充發(fā)布目錄之后，創(chuàng)建tar（或shar）文件之前運(yùn)行。使用該功能的一種方式是發(fā)布新的`Makefile.am'被刪除了的子目錄中的文件。

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

Automake還生成一個(gè)distcheck目標(biāo)，它有助于確認(rèn)給定的發(fā)布版本實(shí)際上是可以工作的。 distcheck首先創(chuàng)建發(fā)布版本，而后試圖進(jìn)行一個(gè)VPATH創(chuàng)建。

對測試套件的支持

Automake支持兩種形式的測試套件。

如果定義了變量TESTS，它的值被看作為了運(yùn)行測試而運(yùn)行的程序列表。程序可以是派生對象或者是源對象；生成的規(guī)則將在srcdir和`.'中尋找。應(yīng)該在srcdir（它可以既是環(huán)境變量，又是make變量）中尋找程序需要的數(shù)據(jù)文件，所以它們在一個(gè)分離的目錄中進(jìn)行創(chuàng)建的工作（參見Autoconf手冊中的`創(chuàng)建目錄'節(jié)），并且是在特別的目標(biāo)distcheck中創(chuàng)建的（參見那些需要被發(fā)布）。

在運(yùn)行的終點(diǎn)將打印失敗的次數(shù)。如果一個(gè)測試程序以狀態(tài)77退出，在最后的計(jì)數(shù)中它的結(jié)果將被忽略。這一特征允許不可移植的測試在對它來說沒有意義的環(huán)境下被忽略。

變量TESTS_ENVIRONMENT可以用于為測試運(yùn)行而設(shè)置環(huán)境變量；在該規(guī)則中設(shè)置環(huán)境變量srcdir。如果你所有的測試程序都是腳本，你還可以把TESTS_ENVIRONMENT設(shè)置成一個(gè)對shell的調(diào)用（例如`$(SHELL) -x'）；這對調(diào)試測試結(jié)果來說是有用的。

如果`dejagnu'出現(xiàn)在AUTOMAKE_OPTIONS中，那么就假定運(yùn)行一個(gè)基于dejagnu的測試套件。變量 DEJATOOL的值被作為--tool的參數(shù)傳遞給 runtest；它的缺省值是包的名字。

在缺省狀態(tài)下，變量RUNTESTDEFAULTFLAGS保存了傳遞給dejagnu的--tool和--srcdir選項(xiàng)；如果有必要，可以覆蓋它。

還可以覆蓋變量EXPECT、RUNTEST和RUNTESTFLAGS以提供項(xiàng)目特定的值。例如，如果你正在測試編譯器工具鏈（toolchain），你就需要這樣做。這是因?yàn)槿笔≈挡]有把主機(jī)名和目標(biāo)名考慮進(jìn)去。

在上述兩種情況中，測試都是通過`make check'來完成的。

改變Automake的行為

Automake的各種特征可以在`Makefile.am'中用各種選項(xiàng)進(jìn)行控制。這些選項(xiàng)在一個(gè)名為AUTOMAKE_OPTIONS的特殊變量中被列出。目前可以理解的選項(xiàng)有：

gnits

gnu

foreign

cygnus

設(shè)置適當(dāng)?shù)膰?yán)格性。選項(xiàng)gnits還隱含了readme-alpha和check-news。

ansi2knr

path/ansi2knr

打開自動(dòng)de-ANSI-fication功能。參見自動(dòng)de-ANSI-fication。如果以一個(gè)路徑開頭，那么生成的`Makefile.in'將在特別給定的目錄中尋找程序`ansi2knr'。通常，路徑應(yīng)該是到同一個(gè)發(fā)布版本中的其它目錄的相對路徑（雖然Automake并不進(jìn)行這項(xiàng)檢查）。

check-news

給出該選項(xiàng)后，如果當(dāng)前的版本號沒有出現(xiàn)在`NEWS'文件中的前幾行中，將導(dǎo)致make dist的失敗。

dejagnu

生成dejagnu特定的規(guī)則。參見對測試套件的支持。

dist-shar

就象普通的dist目標(biāo)那樣生成dist-shar目標(biāo)。這個(gè)新目標(biāo)將創(chuàng)建一個(gè)發(fā)布版本的shar包。

dist-zip

就象普通的dist目標(biāo)那樣生成dist-zip目標(biāo)。這個(gè)新目標(biāo)將創(chuàng)建一個(gè)發(fā)布版本的zip包。

dist-tarZ

就象普通的dist目標(biāo)那樣生成dist-tarZ目標(biāo)。這個(gè)新目標(biāo)將創(chuàng)建一個(gè)發(fā)布版本的tar包；假定使用傳統(tǒng)的tar 和compress。警告：如果你實(shí)際上在使用GNU tar，那么生成的包可能含有不可移植的結(jié)構(gòu)。

no-dependencies

這與在命令行中使用選項(xiàng)`--include-deps'相類似，但在那些你不希望使用自動(dòng)依賴性跟蹤的場合下更為有用。參見自動(dòng)依賴性跟蹤。在這個(gè)情況下將有效地關(guān)閉自動(dòng)依賴性跟蹤。

no-installinfo

給出該選項(xiàng)后，生成的`Makefile.in'在缺省的狀態(tài)下將不會(huì)創(chuàng)建或者安裝info文檔。然而，目標(biāo)info和目標(biāo)install-info 仍然是可用的安裝選項(xiàng)。在`GNU'嚴(yán)格性以及更高的嚴(yán)格性中這個(gè)選項(xiàng)是不允許使用的。

no-installman

給出這個(gè)選項(xiàng)后，生成的`Makefile.in'在缺省狀態(tài)下將不會(huì)安裝man手冊。然而，目標(biāo)install-man仍然是可用的安裝選項(xiàng)。在`GNU'嚴(yán)格性以及更高的嚴(yán)格性中這個(gè)選項(xiàng)是不允許使用的。

no-texinfo.tex

即使在本目錄中含有texinfo文件，也不需要`texinfo.tex'

readme-alpha

如果本發(fā)布是一個(gè)alpha版本，并且存在文件`README-alpha'，那么它將被添加到發(fā)布版本中。如果給出了該選項(xiàng)，版本號應(yīng)該是以下兩種形式之一。第一種形式是`MAJOR.MINOR.ALPHA'，其中每個(gè)元素都是一個(gè)數(shù)字；最后的點(diǎn)和數(shù)字應(yīng)該被忽略以用于非alpha版本。第二種形式是`MAJOR.MINORALPHA'，其中ALPHA是一個(gè)文字；對于非alpha版本來說，應(yīng)該忽略它。

version

可以給出版本號（例如，`0.30'）。如果Automake并不比要求的版本號新，將不會(huì)創(chuàng)建`Makefile.in'。

automake能夠診斷不能識別的選項(xiàng)。

其它規(guī)則

還有一些不適于放在任何其它地方的幾條規(guī)則。

與etags之間的界面

在某些環(huán)境下，automake將生成規(guī)則以產(chǎn)生由GNU Emacs使用的`TAGS'文件。

如果出現(xiàn)了任何C源代碼或者頭文件，那么就為該目錄創(chuàng)建目標(biāo)tags和目標(biāo)TAGS。

在運(yùn)行的時(shí)候，將在多個(gè)目錄包的頂層目錄創(chuàng)建一個(gè)tags文件，它將生成一個(gè)包括了對所有子目錄的`TAGS'文件的引用的`TAGS'文件。

此外，如果定義了變量ETAGS_ARGS，將生成目標(biāo)tags。該變量用于包含了能夠被標(biāo)記，但是不能夠被etags所識別的源文件的目錄。

下面是Automake如何為它的源代碼生成標(biāo)記和它的Texinfo文件中的結(jié)點(diǎn)。

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

如果你把文件名添加到`ETAGS_ARGS'，你將可能還要設(shè)置`TAGS_DEPENDENCIES'。該變量的內(nèi)容將直接添加到目標(biāo)tags的依賴列表中。

Automake還將生成一個(gè)將在源代碼上運(yùn)行mkid的ID目標(biāo)。它僅僅可以在一個(gè)目錄到目錄的基礎(chǔ)（directory-by-directory basis）上使用。

處理新的文件擴(kuò)展名

有時(shí)，為處理Automake不能識別的文件類型而引入新的隱含規(guī)則是有用的。如果這樣做，你必須把這些新的后綴告訴GNU Make。可以通過把新后綴的列表添加到變量SUFFIXES來完成。

例如，目前automake不能對Java提供任何支持。如果你寫了一個(gè)用于從`.java' 源文件生成`.class'文件的宏，你還需要把這些后綴添加到列表中：

SUFFIXES = .java .class

條件

Automake支持一種簡單的條件。

在使用條件之前，你必須在configure.in文件中使用 AM_CONDITIONAL定義它。宏AM_CONDITIONAL 接受兩個(gè)參數(shù)。

AM_CONDITIONAL的第一個(gè)參數(shù)是條件的名字。它應(yīng)該是一個(gè)以字母開頭并且僅僅由字母、數(shù)字和下劃線組成的簡單字符串。

AM_CONDITIONAL的第二個(gè)參數(shù)是一個(gè)適用于shell的if語句的shell條件。該條件將在運(yùn)行configure的時(shí)候被求值。

條件典型地依賴于用戶提供給configure腳本的選項(xiàng)。下面是一個(gè)演示如果在用戶使用了`--enable-debug'選項(xiàng)的情況下為真的條件的例子。

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)

下面是一個(gè)如何在`Makefile.am'中使用條件的例子：

if DEBUG
DBG = debug
else
DBG =
endif
noinst_PROGRAMS = $(DBG)

這個(gè)小例子還可以被處理以用于EXTRA_PROGRAMS。（參見創(chuàng)建一個(gè)程序）。

你只能在if語句中測試單個(gè)變量。可以忽略else語句。條件可以嵌套到任意深度。

需要指出的是Automake中的條件與GNU Make中的條件是不相同的。Automake的條件在配置時(shí)刻由`configure'腳本完成檢查，并且將影響`Makefile.in'到`Makefile'的轉(zhuǎn)換。它們是基于傳遞給`configure'的選項(xiàng)和`configure'對本地系統(tǒng)的檢測結(jié)果的。 GNU Make條件則在make時(shí)完成檢查，并且是基于傳遞給make程序的變量或者是基于在`Makefile'中定義的變量的。

Automake條件在任何make下都可以工作。

--gnu和--gnits的效果

選項(xiàng)`--gnu'（或者`AUTOMAKE_OPTIONS'中的`gnu'）將使得 automake執(zhí)行如下檢查：

• 在包的頂層目錄中應(yīng)該含有文件`INSTALL'、`NEWS'、`README'、`COPYING'、 `AUTHORS'和`ChangeLog'。
• 禁止使用選項(xiàng)`no-installman'和`no-installinfo'。

需要指出的是，該選項(xiàng)將在未來進(jìn)行擴(kuò)展以進(jìn)行更多的檢查；熟悉GNU標(biāo)準(zhǔn)的精確需求是值得推薦的。此外，`--gnu'可以要求某些非標(biāo)準(zhǔn)GNU程序?yàn)榱烁鞣N僅由維護(hù)者使用的目標(biāo)而存在；例如，在將來`make dist'可能會(huì)需要pathchk。

選項(xiàng)`--gnits'進(jìn)行`--gnu'所做的所有檢查，此外還進(jìn)行如下檢查：

• `make dist'將檢查以確認(rèn)文件`NEWS'被更新到當(dāng)前的版本。
• 不允許出現(xiàn)文件`COPYING.LIB'。LGPL顯然是一個(gè)失敗的試驗(yàn)。
• 檢查文件`VERSION'以確保它的格式是符合Gnits標(biāo)準(zhǔn)的。
• 如果`VERSION'表明本版本是alpha版本，并且文件`README-alpha' 出現(xiàn)在包的頂層目錄中，那么它就被包含在發(fā)布版本中。因?yàn)樵撃Ｊ绞俏ㄒ粚Π姹咎柛袷綄?shí)行限制的模式，所以上述操作在`--gnits' 模式下實(shí)施而不在其它模式下進(jìn)行，因此，該模式也是automake唯一能夠自動(dòng)確定是否把`README-alpha'包含在發(fā)布版本中的模式。
• 需要出現(xiàn)文件`THANKS'。

--cygnus的效果

對于如何構(gòu)造`Makefile.in'，Cygnus解決方案有一些不同的規(guī)則。把`--cygnus'傳遞給automake將使所有生成的`Makefile.in' 服從Cygnus規(guī)則。

下面是`--cygnus'的精確效果：

• 總是在創(chuàng)建目錄中，而不是在源目錄創(chuàng)建Info文件。
• 如果指明了Texinfo源文件，就不需要`texinfo.tex'。其設(shè)想是：應(yīng)該提供該文件，但automake不能在適當(dāng)?shù)奈恢谜业剿＿@種設(shè)想是Cygnus包典型的包裝方式的產(chǎn)物。
• `make dist'將在創(chuàng)建目錄和源目錄中尋找文件。為了支持把info文件儲存在創(chuàng)建目錄中而提供這個(gè)功能。
• 將在創(chuàng)建樹和用戶的`PATH'中尋找某些工具。這些工具是runtest、 expect、makeinfo和texi2dvi。
• 隱含--foreign選項(xiàng)。
• 隱含選項(xiàng)`no-installinfo'和選項(xiàng)`no-dependencies'。
• 需要宏`AM_MAINTAINER_MODE'和宏`AM_CYGWIN32'。
• 目標(biāo)check并不依賴于目標(biāo)all。

建議GNU維護(hù)者使用`gnu'嚴(yán)格性方式而不是特殊的Cygnus模式。

什么時(shí)候Automake不夠用

Automake的隱含語義意味著許多問題只要通過把一些make 目標(biāo)和規(guī)則添加到`Makefile.in'中就可以解決了。 automake將忽略這些添加的目標(biāo)和規(guī)則。

對于這種做法需要提出告誡。雖然你可以覆蓋已經(jīng)被automake所使用的目標(biāo)，但這通常是失策的，在非平包（non-flat）的頂層目錄中尤其如此。然而，你可以在你的`Makefile.in'中給出各種帶有`-local'的有用目標(biāo)版本。 Automake將用那些用戶提供的目標(biāo)補(bǔ)充標(biāo)準(zhǔn)的目標(biāo)。

支持本地版本的目標(biāo)有all、info、dvi、 check、install-data、install-exec、 uninstall和各種clean目標(biāo)（mostlyclean、clean、distclean和 maintainer-clean）。需要指出的是沒有 uninstall-exec-local或者uninstall-data-local目標(biāo)；請使用uninstall-local。僅僅反安裝數(shù)據(jù)或僅僅反安裝可執(zhí)行文件是沒有意義的。

例如，下面是把一個(gè)文件安裝到`/etc'的一種方式：

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

某些目標(biāo)還可以在完成它的工作之后運(yùn)行一個(gè)稱為hook的其它目標(biāo)。 hook是在源目標(biāo)名的后面添加`-hook'。允許使用hook的目標(biāo)是 install-data、install-exec、dist和 distcheck。

例如，下面是如果創(chuàng)建一個(gè)到已經(jīng)安裝的程序的硬連接：

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

發(fā)布`Makefile.in'

Automake對于發(fā)布生成的`Makefile.in'沒有施加任何限制。我們?nèi)匀还膭?lì)軟件的作者按照諸如GPL之類的條款發(fā)布它們的作品，但是Automake 并不要求你這樣做。

一些可以通過選項(xiàng)--add-missing自動(dòng)安裝的文件則受到 GPL的約束；打開每個(gè)文件檢查一下。