[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_CONFIG_FILES/AC_CONFIG_COMMANDS lossage
From: |
Akim Demaille |
Subject: |
Re: AC_CONFIG_FILES/AC_CONFIG_COMMANDS lossage |
Date: |
Wed, 20 Nov 2002 18:34:21 +0100 |
User-agent: |
Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) |
Thien-Thi> From: Akim Demaille <address@hidden>
Thien-Thi> Date: Wed, 20 Nov 2002 13:04:01 +0100
Thien-Thi> That was a bug.
Thien-Thi> you (additionally, eventually) need to address AC_CONFIG_FILES /
Thien-Thi> AC_CONFIG_COMMANDS interaction -- that is: how should one go about
Thien-Thi> getting both features to work w/ the same tag. that is the deeper
Thien-Thi> question.
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 whitespace-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
TAGs: they may have the form `OUTPUT' or `OUTPUT:INPUTS'. The
file OUTPUT is instantiated from its templates, INPUTS (defaulting
to `OUTPUT.in').
For instance
`AC_CONFIG_FILES(Makefile:boiler/top.mk:boiler/bot.mk)' asks for
the creation of `Makefile' that will be 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 *Note config.status
Invocation::, for more details.
The INPUTS may be absolute or relative filenames. 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 path from the top build directory to the top source
directory. This is what `configure''s option `--srcdir' sets.
`ac_top_srcdir'
The path from the current build directory to the top source
directory.
`ac_top_builddir'
The path from the current build directory to the top build
directory. It can be empty, or else ends with a slash, so
that you may concatenate it.
`ac_srcdir'
The path from the current build directory to the
corresponding source 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_builddir='../../'
# Concatenation of $ac_top_builddir 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' will be 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 TAGs,
of course!
Creating Configuration Files
============================
Be sure to read the previous section, *Note Configuration Actions::.
- Macro: AC_CONFIG_FILES (FILE..., [CMDS], [INIT-CMDS])
Make `AC_OUTPUT' create each `FILE' by copying an input file (by
default `FILE.in'), substituting the output variable values. This
macro is one of the instantiating macros; see *Note Configuration
Actions::. *Note Makefile Substitutions::, for more information
on using output variables. *Note Setting Output Variables::, for
more information on creating them. This macro creates the
directory that the file is in if it doesn't exist. Usually,
`Makefile's are created this way, but other files, such as
`.gdbinit', can be specified as well.
Typical calls to `AC_CONFIG_FILES' look like this:
AC_CONFIG_FILES([Makefile src/Makefile man/Makefile X/Imakefile])
AC_CONFIG_FILES([autoconf], [chmod +x autoconf])
You can override an input file name by appending to FILE a
colon-separated list of input files. Examples:
AC_CONFIG_FILES([Makefile:boiler/top.mk:boiler/bot.mk]
[lib/Makefile:boiler/lib.mk])
Doing this allows you to keep your file names acceptable to
MS-DOS, or to prepend and/or append boilerplate to the file.