Autoconf学习——初始化和输出

4.1 Initializingconfigure

每一个configure脚本都必须在开始的时候调用AC_INIT宏来进行初始化。另外一个必须宏是AC_OUTPUT(see Output)。

— Macro: AC_INIT (package, version, [bug-report], [tarname])

处理任何命令行参数,执行变量初始化和验证。

设置package的名称和version。这些通常使用在--version支持,包括configure。bug-report参数是用户报告bug的email。包的tarname与package是不同的:后者说明完整的包名,而前者是指发布的tar ball名。它默认是package去掉“GNU”前缀,小写,只允许字母数字和“-”。

推荐AC_INIT使用静态参数,如最好不要使用需要计算的任何shell表达式(能够被M4计算)。

下列M4宏(如AC_PACKAGE_NAME),输出变量(如PACKAGE_NAME)和预处理器符号(如PACKAGE_NAME),被定义在AC_INIT宏中。

AC_PACKAGE_NAME, PACKAGE_NAME
Exactly package.
AC_PACKAGE_TARNAME, PACKAGE_TARNAME
Exactly tarname.
AC_PACKAGE_VERSION, PACKAGE_VERSION
Exactly version.
AC_PACKAGE_STRING, PACKAGE_STRING
Exactly `package version'.
AC_PACKAGE_BUGREPORT, PACKAGE_BUGREPORT
Exactly bug-report.

If yourconfigurescript does its own option processing, it should inspect  immediately after calling AC_INIT, because other Autoconf macros liberally use thesetcommand to process strings, and this has the side effect of updating `$@' and `$*'. However, we suggest that you use standard macros like AC_ARG_ENABLE instead of attempting to implement your own option processing. See Site Configuration.

4.2 Dealing with Autoconf versions

下面列出的宏能够帮助用户选择成功编译一个指定的configure.ac文件的Autoconf的最小版本。

— Macro: AC_PREREQ (version)

这个宏限定了用于创建configure文件的Autoconf的最小版本,如果Autoconf的版本早于指定的版本,那么将会打印一个错误消息到标准输出中并退出,退出状态是63。譬如:

          AC_PREREQ([2.63])
    

这个宏是唯一一个可以在AC_INIT宏之前使用的宏,但一般不推荐这样做。

— Macro: AC_AUTOCONF_VERSION

这个宏在Autoconf2.62中引进。它用适合于m4_version_compare (see m4_version_compare)的格式标识当前用于分析输入文件的Autoconf的版本;譬如'2.63'。  One potential use of this macro is for writing conditional fallbacks based on when a feature was added to Autoconf, rather than using AC_PREREQto require the newer version of Autoconf. However, remember that the Autoconf philosophy favors feature checks over version checks.

You should not expand this macro directly; use `m4_defn([AC_AUTOCONF_VERSION])' instead. This is because some users might have a beta version of Autoconf installed, with arbitrary letters included in its version string. This means it is possible for the version string to contain the name of a defined macro, such that expanding AC_AUTOCONF_VERSION would trigger the expansion of that macro during rescanning, and change the version string to be different than what you intended to check.

4.3 Notices inconfigure

下列的宏为configure脚本管理版本号,这些宏是可选的。

— Macro: AC_COPYRIGHT (copyright-notice)

State that, in addition to the Free Software Foundation's copyright on the Autoconf macros, parts of yourconfigureare covered by the copyright-notice.

The copyright-noticeshows up in both the head ofconfigureand in `configure --version'.

— Macro: AC_REVISION (revision-info)

Copy revision stamp revision-infointo theconfigurescript, with any dollar signs or double-quotes removed. This macro lets you put a revision stamp fromconfigure.acintoconfigurewithout RCS or CVSchanging it when you check inconfigure. That way, you can determine easily which revision ofconfigure.aca particularconfigurecorresponds to.

For example, this line inconfigure.ac:

          AC_REVISION([$Revision: 1.30 $])
     

produces this inconfigure:

          #!/bin/sh
          # From configure.ac Revision: 1.30

4.4 FindingconfigureInput

— Macro: AC_CONFIG_SRCDIR (unique-file-in-source-dir)

unique-file-in-source-diris some file that is in the package's source directory;configurechecks for this file's existence to make sure that the directory that it is told contains the source code in fact does. Occasionally people accidentally specify the wrong directory with--srcdir; this is a safety check. See configure Invocation, for more information.

Packages that do manual configuration or use theinstallprogram might need to tellconfigurewhere to find some other shell scripts by calling AC_CONFIG_AUX_DIR, though the default places it looks are correct for most cases.

— Macro: AC_CONFIG_AUX_DIR (dir)

Use the auxiliary build tools (e.g.,install-sh,config.sub,config.guess, Cygnusconfigure, Automake and Libtool scripts, etc.) that are in directory dir. These are auxiliary files used in configuration. dircan be either absolute or relative tosrcdir. The default issrcdirorsrcdir/..orsrcdir/../.., whichever is the first that containsinstall-sh. The other files are not checked for, so that using AC_PROG_INSTALLdoes not automatically require distributing the other auxiliary files. It checks forinstall.shalso, but that name is obsolete because somemakehave a rule that createsinstallfrom it if there is no makefile.

The auxiliary directory is commonly namedbuild-aux. If you need portability to DOSvariants, do not name the auxiliary directoryaux. See File System Conventions.

— Macro: AC_REQUIRE_AUX_FILE (file)

Declares that file is expected in the directory defined above. In Autoconf proper, this macro does nothing: its sole purpose is to be traced by third-party tools to produce a list of expected auxiliary files. For instance it is called by macros like AC_PROG_INSTALL (see Particular Programs) or AC_CANONICAL_BUILD (see Canonicalizing) to register the auxiliary files they need.

Similarly, packages that useaclocalshould declare where local macros can be found using AC_CONFIG_MACRO_DIR.

— Macro: AC_CONFIG_MACRO_DIR (dir)

Specify diras the location of additional local Autoconf macros. This macro is intended for use by future versions of commands likeautoreconfthat trace macro calls. It should be called directly fromconfigure.acso that tools that install macros foraclocalcan find the macros' declarations.

Note that if you useaclocalfrom Automake to generateaclocal.m4, you must also set ACLOCAL_AMFLAGS = -I dirin your top-levelMakefile.am. Due to a limitation in the Autoconf implementation ofautoreconf, these include directives currently must be set on a single line inMakefile.am, without any backslash-newlines.

4.5 Outputting Files

Every Autoconf script, e.g.,configure.ac, should finish by calling AC_OUTPUT. That is the macro that generates and runsconfig.status, which in turn creates the makefiles and any other files resulting from configuration. This is the only required macro besides AC_INIT (see Input).

— Macro: AC_OUTPUT

Generateconfig.statusand launch it. Call this macro once, at the end ofconfigure.ac.

config.statusperforms all the configuration actions: all the output files (see Configuration Files, macro AC_CONFIG_FILES), header files (see Configuration Headers, macro AC_CONFIG_HEADERS), commands (see Configuration Commands, macro AC_CONFIG_COMMANDS), links (see Configuration Links, macro AC_CONFIG_LINKS), subdirectories to configure (see Subdirectories, macro AC_CONFIG_SUBDIRS) are honored.

The location of your AC_OUTPUTinvocation is the exact point where configuration actions are taken: any code afterwards is executed byconfigureonceconfig.statuswas run. If you want to bind actions toconfig.statusitself (independently of whetherconfigureis being run), see Running Arbitrary Configuration Commands.

Historically, the usage of AC_OUTPUT was somewhat different. See Obsolete Macros, for a description of the arguments that AC_OUTPUTused to support.

If you runmakein subdirectories, you should run it using themakevariable MAKE. Most versions ofmakeset MAKEto the name of themakeprogram plus any options it was given. (But many do not include in it the values of any variables set on the command line, so those are not passed on automatically.) Some old versions ofmakedo not set this variable. The following macro allows you to use it even with those versions.

— Macro: AC_PROG_MAKE_SET

If the Make command, $MAKEif set or else `make', predefines $(MAKE), define output variable SET_MAKE to be empty. Otherwise, define SET_MAKE to a macro definition that sets $(MAKE), such as `MAKE=make'. Calls AC_SUBST for SET_MAKE.

If you use this macro, place a line like this in eachMakefile.inthat runsMAKEon other directories:

     @SET_MAKE@

4.6 Performing Configuration Actions

configureis designed so that it appears to do everything itself, but there is actually a hidden slave:config.status.configureis in charge of examining your system, but it isconfig.statusthat actually takes the proper actions based on the results ofconfigure. The most typical task ofconfig.statusis to instantiatefiles.

This section describes the common behavior of the four standard instantiating macros: AC_CONFIG_FILES, AC_CONFIG_HEADERS, AC_CONFIG_COMMANDS and AC_CONFIG_LINKS. They all have this prototype:

     AC_CONFIG_FOOS(tag..., [commands], [init-cmds])

where the arguments are:

tag...
A blank-or-newline-separated list of tags, which are typically the names of the files to instantiate.

You are encouraged to use literals as tags. In particular, you should avoid

          ... && my_foos="$my_foos fooo"
          ... && my_foos="$my_foos foooo"
          AC_CONFIG_FOOS([$my_foos])
     

and use this instead:

          ... && AC_CONFIG_FOOS([fooo])
          ... && AC_CONFIG_FOOS([foooo])
     

The macros AC_CONFIG_FILES and AC_CONFIG_HEADERS use special tagvalues: they may have the form `output' or `output:inputs'. The file output is instantiated from its templates, inputs(defaulting to `output.in').

`AC_CONFIG_FILES([Makefile:boiler/top.mk:boiler/bot.mk)]', for example, asks for the creation of the fileMakefilethat contains the expansion of the output variables in the concatenation ofboiler/top.mkandboiler/bot.mk.

The special value `-' might be used to denote the standard output when used in output, or the standard input when used in the inputs. You most probably don't need to use this inconfigure.ac, but it is convenient when using the command line interface of./config.status, see config.status Invocation, for more details.

The inputs may be absolute or relative file names. In the latter case they are first looked for in the build tree, and then in the source tree.

commands
Shell commands output literally intoconfig.status, and associated with a tag that the user can use to tellconfig.statuswhich the commands to run. The commands are run each time a tagrequest is given toconfig.status, typically each time the filetagis created.

The variables set during the execution ofconfigureare not available here: you first need to set them via the init-cmds. Nonetheless the following variables are precomputed:

srcdir
The name of the top source directory, assuming that the working directory is the top build directory. This is what theconfigureoption--srcdirsets.
ac_top_srcdir
The name of the top source directory, assuming that the working directory is the current build directory.
ac_top_build_prefix
The name of the top build directory, assuming that the working directory is the current build directory. It can be empty, or else ends with a slash, so that you may concatenate it.
ac_srcdir
The name of the corresponding source directory, assuming that the working directory is the current build directory.

The current directory refers to the directory (or pseudo-directory) containing the input part of tags. For instance, running

          AC_CONFIG_COMMANDS([deep/dir/out:in/in.in], [...], [...])
     

with--srcdir=../packageproduces the following values:

          # Argument of --srcdir
          srcdir='../package'
          # Reversing deep/dir
          ac_top_build_prefix='http://www.cnblogs.com/'
          # Concatenation of $ac_top_build_prefix and srcdir
          ac_top_srcdir='http://www.cnblogs.com/../package'
          # Concatenation of $ac_top_srcdir and deep/dir
          ac_srcdir='http://www.cnblogs.com/../package/deep/dir'
     

independently of `in/in.in'.

init-cmds
Shell commands output unquotednear the beginning ofconfig.status, and executed each timeconfig.statusruns (regardless of the tag). Because they are unquoted, for example, `$var' is output as the value of var. init-cmdsis typically used byconfigureto giveconfig.statussome variables it needs to run the commands.

You should be extremely cautious in your variable names: all the init-cmds share the same name space and may overwrite each other in unpredictable ways. Sorry....

All these macros can be called multiple times, with different tag values, of course!

posted @ 2011-03-16 19:41  茫茫深海一条鱼  阅读(1228)  评论(0)    收藏  举报