|
4.5 Performing Configuration Actions
configure is designed so that it appears to do everything itself,
but there is actually a hidden slave: config.status.
configure is in charge of examining your system, but it is
config.status that actually takes the proper actions based on the
results of configure. The most typical task of
config.status is to instantiate files.
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 tag values: 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 file Makefile that contains the expansion of the
output variables in the concatenation of boiler/top.mk and
boiler/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 in
configure.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 into config.status, and
associated with a tag that the user can use to tell config.status
which the commands to run. The commands are run each time a tag
request is given to config.status, typically each time the file
tag is created.
The variables set during the execution of configure are
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 the configure option --srcdir sets.
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=../package produces the following values:
# Argument of --srcdir
srcdir='../package'
# Reversing deep/dir
ac_top_build_prefix='../../'
# Concatenation of $ac_top_build_prefix and srcdir
ac_top_srcdir='../../../package'
# Concatenation of $ac_top_srcdir and deep/dir
ac_srcdir='../../../package/deep/dir'
independently of ‘in/in.in’.
- init-cmds
- Shell commands output unquoted near the beginning of
config.status, and executed each time config.status runs
(regardless of the tag). Because they are unquoted, for example,
‘$var’ is output as the value of
var . init-cmds
is typically used by configure to give config.status some
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!
|
|