GNU Automake.docx
- 文档编号:30146296
- 上传时间:2023-08-05
- 格式:DOCX
- 页数:48
- 大小:46.70KB
GNU Automake.docx
《GNU Automake.docx》由会员分享,可在线阅读,更多相关《GNU Automake.docx(48页珍藏版)》请在冰豆网上搜索。
GNUAutomake
GNUAutomake
Forversion1.3,3April1998
DavidMacKenzieandTomTromey
目录
∙介绍
∙通用性概念
o通用操作
o深度
o严格性
o统一命名机制
o派生变量是如何命名的
∙一些实例软件包
o一个简单的例子,从起点到终点
o一个经典的程序
o创建etags和ctags
∙创建`Makefile.in'
∙扫描`configure.in'
o配置需求
oAutomake能够识别的其它事情
o自动生成的aclocal.m4
o由Automake支持的Autoconf宏
o编写你自己的aclocal宏
∙顶层`Makefile.am'
∙创建程序和库
o创建一个程序
o创建一个库
o对LIBOBJS和ALLOCA的特别处理
o创建一个共享库
o创建一个程序时使用的变量
o对Yacc和Lex的支持
oC++和其它语言
o自动de-ANSI-fication
o自动的依赖性(dependency)跟踪
∙其它派生对象
o可执行的脚本
o头文件
o与体系结构无关(Architecture-independent)的数据文件
o已创建的源代码
∙其它GNU工具
oEmacsLisp
oGettext
oGuile
oLibtool
oJava
∙创建文档
oTexinfo
oMan手册
∙安装了些什么
∙清除了些什么
∙需要发布哪些文件
∙对测试套件(testsuites)的支持
∙改变Automake的行为
∙其它规则
o与etags之间的界面
o处理新的文件扩展名
∙条件(Conditionals)
∙--gnuand--gnits的效果
∙--cygnus的效果
∙什么时候Automake不够用
∙发布`Makefile.in'
∙未来的某些想法
∙索引
@dircategoryGNUadmin@direntry*automake:
(automake).MakingMakefile.in's
@dircategoryIndividualutilities@direntry*aclocal:
(automake)Invokingaclocal.Generatingaclocal.m4
Copyright(C)1995,96FreeSoftwareFoundation,Inc.
这是GNUAutomake文档的第一版,
并且是针对GNUAutomake1.3的。
自由软件基金会出版
59TemplePlace-Suite330,
Boston,MA02111-1307USA
Permissionisgrantedtomakeanddistributeverbatimcopiesofthismanualprovidedthecopyrightnoticeandthispermissionnoticearepreservedonallcopies.
Permissionisgrantedtocopyanddistributemodifiedversionsofthismanualundertheconditionsforverbatimcopying,providedthattheentireresultingderivedworkisdistributedunderthetermsofapermissionnoticeidenticaltothisone.
Permissionisgrantedtocopyanddistributetranslationsofthismanualintoanotherlanguage,undertheaboveconditionsformodifiedversions,exceptthatthispermissionnoticemaybestatedinatranslationapprovedbytheFreeSoftwareFoundation.
只要版权声明和本许可声明保留在所有副本中,您就被授权制作和发行本手册的原文副本。
只要整个最终派生工作按照与本手册相同的许可声明发行,您就被授权按照与发行原文相同的条件复制和发行本手册的修改版本。
除了本许可声明应该使用由基金会批准的译文之外,您被授权按照与上述修改版本相同的条件复制和发行本手册的其它语言的译文。
本文档由王立翻译。
1999.12.17
译者在此声明:
不对任何由译文错误或者对译文的误解承担任何责任。
介绍
Automake是一个从文件`Makefile.am'自动生成`Makefile.in'的工具。
每个`Makefile.am'基本上是一系列make的宏定义(make规则也会偶尔出现)。
生成的`Makefile.in's服从GNUMakefile标准。
GNUMakefile标准文档(参见GNU编码标准中的‘Makefile惯例’节)长、复杂,而且会发生改变。
Automake的目的就是解除个人GNU维护者维护Makefile的负担(并且让Automake的维护者来承担这个负担)。
典型的Automake输入文件是一系列简单的宏定义。
处理所有这样的文件以创建`Makefile.in'。
在一个项目(project)的每个目录中通常包含一个`Makefile.am'。
Automake在几个方面对一个项目做了限制;例如它假定项目使用Autoconf(参见Autoconf手册),并且对`configure.in'的内容施加了某些限制。
为生成`Makefile.in',Automake需要perl。
但是由Automake创建的发布完全服从GNU标准,并且在创建中不需要perl。
请把关于Automake的建议和bug发送到automake-bugs@gnu.org。
通用性概念
一些基本概念将有助于理解Automake是如何工作的。
通用操作
Automake读入`Makefile.am'并且生成`Makefile.in'。
在`Makefile.am'中定义的一些宏和目标(targets)指挥automake生成更多特定的代码;例如一个`bin_PROGRAMS'宏定义将生成一个需要被编译、连接的目标。
`Makefile.am'中的宏定义和目标被复制到生成的文件中。
这使得你可以把任何代码添加到生成的`Makefile.in'文件中。
例如,Automake的发布包含了非标准的cvs-dist目标,Automake的维护者用它从他的版本控制系统中创建发布版本。
Automake不能识别GNU对make的扩展。
在`Makefile.am'中使用这些扩展将导致错误或者令人不解的行为。
Automake试图明智地把注释和相邻的目标(或者变量定义)关联起来。
在`Makefile.am'中定义的目标通常覆盖了所有由automake自动生成的拥有相似名字的目标。
虽然Automake提供了这一功能,但最好避免使用它,因为有些时候生成的规则将是十分特别的。
类似地,在`Makefile.am'中定义的变量将覆盖任何通常由automake创建的变量定义。
该功能比覆盖目标定义的功能要常用得多。
需要警告的是许多由automake生成的变量都被认为是内部使用的,并且它们的名字可能在未来的版本中改变。
在检验变量定义的时候,Automake将递归地检验定义中的变量引用。
例如,如果Automake在如下片断中搜索`foo_SOURCES'的内容。
xs=a.cb.c
foo_SOURCES=c.c$(xs)
它将把文件`a.c'、`b.c'和`c.c'作为`foo_SOURCES'的内容。
Automake还允许给出不被复制到输出中的注释;所有以`##'开头的行将被Automake彻底忽略。
作为惯例,`Makefile.am'的第一行是:
##ProcessthisfilewithautomaketoproduceMakefile.in
深度
automake支持三种目录层次:
“flat”、“shallow”和“deep”。
一个flat(平)包指的是所有文件都在一个目录中的包。
为这类包提供的`Makefile.am'缺少宏SUBDIRS。
这类包的一个例子是termutils。
一个deep(深)包指的是所有的源代码都被储存在子目录中的包;顶层目录主要包含配置信息。
GNUcpio是这类包的一个很好的例子,GNUtar也是。
deep包的顶层`Makefile.am'将包括宏SUBDIRS,但没有其它定义需要创建的对象的宏。
一个shallow(浅)包指的是主要的源代码储存在顶层目录中,而各个部分(典型的是库)则储存在子目录中的包。
Automake本身就是这类包(GNUmake也是如此,它现在已经不使用automake)。
严格性
Automake的目的是用于维护GNU包,它为适应那些希望使用它的人做出了一些努力,但并不指望应用所有的GNU惯例。
按照这个目标,Automake支持三级严格性---严格性指的是Automake将如何检查包所服从的标准。
可用的严格性级别有:
`foreign'(外来)
Automake将仅仅检查那些为保证正确操作所必需的事项。
例如,尽管GNU标准指出文件`NEWS'必须存在,在本方式下,并不需要它。
该模式名来自于Automake是被设计成用于GNU程序的事实的;它放松了标准模式的操作规则。
`gnu'
Automake将尽可能地检查包是否服从GNU标准。
这是缺省设置。
`gnits'
Automake将按照还没有完成的Gnits标准进行检查。
它们是基于GNU标准的,但更加详尽。
除非你是Gnits标准的参与奉献者,我们建议您在Gnits标准正式出版之前不要使用这一选项。
关于严格性级别的精确含义的详细说明,参见--gnu和--gnits的效果
统一命名机制
Automake变量通常服从统一的命名机制,以易于确定如何创建和安装程序(和其它派生对象)。
这个机制还支持在运行configure的时候确定应该创建那些对象。
在运行make时,某些变量被用于确定应该创建那些对象。
这些变量被称为主(primary)变量。
例如,主变量PROGRAMS保存了需要被编译和连接的程序的列表。
另一组变量用于确定应该把创建了的对象安装在哪里。
这些变量在主变量之后命名,但是含有一个前缀以指出那个标准目录将作为安装目录。
标准目录名在GNU标准中给出(参见GNU编码标准中的`为DirectoryVariables'节)。
Automake用pkglibdir、pkgincludedir和pkgdatadir扩展了这个列表;除了把`@PACKAGE@'附加其后之外,与非`pkg'版本是相同的。
例如,pkglibdir被定义为$(datadir)/@PACKAGE@.
对于每个主变量,还有一个附加的变量,它的名字是在主变量名之前加一个`EXTRA_'。
该变量用于储存根据configure的运行结果,可能创建、也可能不创建的对象列表。
引入该变量是因为Automake必须静态地知道需要创建的对象的完整列表以创建在所有情况下都能够工作的`Makefile.in'。
例如,在配置时刻cpio确定创建哪些程序。
一部分程序被安装在bindir,还有一部分程序被安装在sbindir:
EXTRA_PROGRAMS=mtrmt
bin_PROGRAMS=cpiopax
sbin_PROGRAMS=@PROGRAMS@
定义没有前缀的主变量(比如说PROGRAMS)是错误的。
在构造变量名的时候,通常省略后缀`dir';因此我们使用`bin_PROGRAMS'而不是`bindir_PROGRAMS'.
不是每种对象都可以安装在任何目录中。
Automake将记录它们以试图找出错误。
Automake还将诊断目录名中明显的拼写错误。
有时标准目录--即使在Automake扩展之后---是不够的。
特别在有些时候,为了清晰起见,把对象安装到预定义目录的子目录中是十分有用的。
为此,Automake允许你扩展可能的安装目录列表。
如果定义了一个添加了后缀`dir'的变量(比如说`zardir'),则给定的前缀(比如`zar')就是合法的。
例如,在HTML支持成为Automake的一部分之前,你可以使用它安装原始的HTML文档。
htmldir=$(prefix)/html
html_DATA=automake.html
特殊前缀`noinst'表示根本不会安装这些有问题的对象。
特殊前缀`check'表示仅仅在运行makecheck命令的时候才创建这些有问题的对象。
可能的主变量名有`PROGRAMS'、`LIBRARIES'、`LISP'、`SCRIPTS'、`DATA'、`HEADERS'、`MANS'和`TEXINFOS'。
派生变量是如何命名的
有时Makefile变量名是从用户提供的某些文本中派生而来的。
例如程序名被重写到Makefile宏名中。
Automake把这些文本规范化,以使它可以不必服从Makefile的变量名规则。
在名字中除了字母、数字和下划线之外的所有字符都将用下划线代替。
例如,如果你的程序被命名为sniff-glue,那么派生出的变量名将是sniff_glue_SOURCES,而不是sniff-glue_SOURCES。
一些实例软件包
一个简单的例子,从起点到终点
让我们假定你刚刚写完zardoz,一个是你的头从一个漩涡漂流到另一个漩涡的程序。
你已经使用了autoconf以提供一个可移植的框架,但你的`Makefile.in'还未完成,所以你需要automake。
第一步是更新你的`configure.in'以包含automake需要的命令。
完成这一步的最简单方式是在AC_INIT之后添加AM_INIT_AUTOMAKE:
AM_INIT_AUTOMAKE(zardoz,1.0)
因为你的程序不含有任何复杂性的因素(例如,它不使用gettext,它不需要共享库),你已经完成了这一步工作。
很容易吧!
现在你必须重新生成`configure'。
但为此,你需要告诉autoconf如何找到你使用的新宏。
完成该任务的最简单的方式是使用aclocal程序为你生成你的`aclocal.m4'。
但是等等...你已经有了一个`aclocal.m4',这是因为你必须为你的程序写一些宏。
aclocal允许你把你自己的宏放到`acinclude.m4'中去,所以简单地改名并且运行:
mvaclocal.m4acinclude.m4
aclocal
autoconf
现在是你为zardoz写的`Makefile.am'的时候了。
zardoz是一个用户程序,所以你需要把它安装到其它用户程序安装的地方去。
zardoz还有一些Texinfo文档。
你的`configure.in'脚本使用AC_REPLACE_FUNCS,因此你需要与`@LIBOBJS@'连接。
所以这里你写:
bin_PROGRAMS=zardoz
zardoz_SOURCES=main.chead.cfloat.cvortex9.cgun.c
zardoz_LDADD=@LIBOBJS@
info_TEXINFOS=zardoz.texi
现在你运行automake--add-missing以生成你的`Makefile.in'并且得到任何你可能需要的附加文件,现在你完成了你的任务!
一个经典的程序
hello因为它经典的简单性和多用性而出名。
本节展示Automake将被如何用于Hello包。
下面的例子来自于最新的GNUHello,但剔除了所有仅为维护者使用的代码和所有的版权注释。
当然,GNUHello比您的传统的两行的代码具有更多的特征。
GNUHello是国际化的,进行选项处理,并且含有一个手册和一个测试套件。
GNUHello是一个deep包。
这里是来自于GNUHello的`configure.in':
dnlProcessthisfilewithautoconftoproduceaconfigurescript.
AC_INIT(src/hello.c)
AM_INIT_AUTOMAKE(hello,1.3.11)
AM_CONFIG_HEADER(config.h)
dnlSetofavailablelanguages.
ALL_LINGUAS="defreskonlnoplptslsv"
dnlChecksforprograms.
AC_PROG_CC
AC_ISC_POSIX
dnlChecksforlibraries.
dnlChecksforheaderfiles.
AC_STDC_HEADERS
AC_HAVE_HEADERS(string.hfcntl.hsys/file.hsys/param.h)
dnlChecksforlibraryfunctions.
AC_FUNC_ALLOCA
dnlCheckforst_blksizeinstructstat
AC_ST_BLKSIZE
dnlinternationalizationmacros
AM_GNU_GETTEXT
AC_OUTPUT([Makefiledoc/Makefileintl/Makefilepo/Makefile.in\
src/Makefiletests/Makefiletests/hello],
[chmod+xtests/hello])
宏`AM_'由Automake(或者Gettext库)提供;其它的是标准Autoconf宏。
顶层`Makefile.am':
EXTRA_DIST=BUGSChangeLog.O
SUBDIRS=docintlposrctests
就像你所见到的,这里的所有工作实际上都是在子目录中完成的。
`po'和`intl'目录是gettextize自动生成的;在这里我们不讨论它们。
在`doc/Makefile.am'中我们看到:
info_TEXINFOS=hello.texi
hello_TEXINFOS=gpl.texi
它足以创建、安装并且发布Hello手册。
这里是`tests/Makefile.am':
TESTS=hello
EXTRA_DIST=hello.intestdata
脚本`hello'是由configure生成的,并且仅仅在测试时才生成。
makecheck将运行这个测试。
最后我们有`src/Makefile.am',所有实际工作在此完成:
bin_PROGRAMS=hello
hello_SOURCES=hello.cversion.cgetopt.cgetopt1.cgetopt.hsystem.h
hello_LDADD=@INTLLIBS@@ALLOCA@
localedir=$(datadir)/locale
INCLUDES=-I../intl-DLOCALEDIR=\"$(localedir)\"
创建etags和ctags
这里是另一个复杂一些的例子。
它展示了如何从同一个源文件(`etags.c')生成两个程序(ctags和etags)。
困难的部分是对`etags.c'的每个编译需要不同的cpp选项。
bin_PROGRAMS=etagsctags
ctags_SOURCES=
ctags_LDADD=ctags.o
etags.o:
etags.c
$(COMPILE)-DETAGS_REGEXPS-cetags.c
ctags.o:
etags.c
$(COMPILE)-DCTAGS-octags.o-cetags.c
其中ctags_SOURCES被定义为空--这种方式表明没有替换隐含的值然而,隐含的值被用于从`etags.o'生成etags。
ctags_LDADD用于把`ctags.o'添加到连接行中。
ctags_DEPENDENCIES由Automake生成。
如果你的编译器不接受`-c'和`-o',那么上述规则将不能工作。
对此,最简单的修正是引入伪依赖(bogusdependency)(以避免由并行make所导致的问题):
etags.o:
etags.cctags.o
$(COMPILE)-DETAGS_REGEXPS-cetags.c
ctags.o:
etags.c
$(COMPILE)-DCTAGS-cetags.c&&mvetags.octags.o
同样,如果使用了de-ANSI-fication的特征,这些显式规则将不能工作;支持它需要一些更多的工作:
etags._o:
etags._cctags.o
$(COMPILE)-DETAGS_REGEXPS-cetags.c
ctags._o:
etags._c
$(COMPILE)-DCTAGS-cetags.c&&mvetags._octags.o
创建`Makefile.in'
为了为一个包创建所有的`Makefile.in',在顶层目录不带任何参数地运行automake。
automake将自动地寻找每个合适的`Makefile.am'(通过扫描`configure.in';参见扫描`configure.in')并生成相应的`Makefile.in'。
automake认为包的组成是相当简单的;它假定包仅仅在顶层目录含有一个`configure.in'。
如果你的包含有多个`configure.in',那么你必须在每个含有`configure.in'的目录中运行automake。
你偶尔可能需要给automake参数;`.am'被添加到参数之后并且其结果将作为输入文件名。
该特征通常仅仅用于自动重新创建一个过时的`Makefile.in'。
automake必须总是在项目的最顶层目录中运行,即使用于重新生成某些子目录中的`Makefile.in'也是如此。
这是因为automake必须扫描`configure.in',并且因为在某些情况下,automake根据`Makefile.in'在子目录中这一情况确定它的行为。
automake接受以下选项:
-a
--add-missing
Automake要求一些通用文件在特定的位置存在。
例如如果`conf
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- GNU Automake