File: autoconf.info, Node: config.status Invocation, Next: Obsolete Constructs, Prev: Running configure Scripts, Up: Top
Recreating a Configuration
**************************
The `configure' script creates a file named `config.status', which
actually configures, "instantiates", the template files. It also
records the configuration options that were specified when the package
was last configured in case reconfiguring is needed.
Synopsis:
./config.status OPTION... [FILE...]
It configures the FILES; if none are specified, all the templates
are instantiated. The files must be specified without their
dependencies, as in
./config.status foobar
not
./config.status foobar:foo.in:bar.in
The supported OPTIONs are:
`--help'
`-h'
Print a summary of the command line options, the list of the
template files, and exit.
`--version'
`-V'
Print the version number of Autoconf and exit.
`--silent'
`--quiet'
`-q'
Do not print progress messages.
`--debug'
`-d'
Don't remove the temporary files.
`--file=FILE[:TEMPLATE]'
Require that FILE be instantiated as if
`AC_CONFIG_FILES(FILE:TEMPLATE)' was used. Both FILE and TEMPLATE
may be `-' in which case the standard output and/or standard
input, respectively, is used. If a TEMPLATE filename is relative,
it is first looked for in the build tree, and then in the source
tree. *Note Configuration Actions::, for more details.
This option and the following ones provide one way for separately
distributed packages to share the values computed by `configure'.
Doing so can be useful if some of the packages need a superset of
the features that one of them, perhaps a common library, does.
These options allow a `config.status' file to create files other
than the ones that its `configure.ac' specifies, so it can be used
for a different package.
`--header=FILE[:TEMPLATE]'
Same as `--file' above, but with `AC_CONFIG_HEADERS'.
`--recheck'
Ask `config.status' to update itself and exit (no instantiation).
This option is useful if you change `configure', so that the
results of some tests might be different from the previous run.
The `--recheck' option re-runs `configure' with the same arguments
you used before, plus the `--no-create' option, which prevents
`configure' from running `config.status' and creating `Makefile'
and other files, and the `--no-recursion' option, which prevents
`configure' from running other `configure' scripts in
subdirectories. (This is so other `Makefile' rules can run
`config.status' when it changes; *note Automatic Remaking::, for
an example).
`config.status' checks several optional environment variables that
can alter its behavior:
- Variable: CONFIG_SHELL
The shell with which to run `configure' for the `--recheck'
option. It must be Bourne-compatible. The default is a shell that
supports `LINENO' if available, and `/bin/sh' otherwise.
- Variable: CONFIG_STATUS
The file name to use for the shell script that records the
configuration. The default is `./config.status'. This variable is
useful when one package uses parts of another and the `configure'
scripts shouldn't be merged because they are maintained separately.
You can use `./config.status' in your Makefiles. For example, in
the dependencies given above (*note Automatic Remaking::),
`config.status' is run twice when `configure.ac' has changed. If that
bothers you, you can make each run only regenerate the files for that
rule:
config.h: stamp-h
stamp-h: config.h.in config.status
./config.status config.h
echo > stamp-h
Makefile: Makefile.in config.status
./config.status Makefile
The calling convention of `config.status' has changed; see *Note
Obsolete config.status Use::, for details.
Generated by $Id: phpMan.php,v 4.55 2007/09/05 04:42:51 chedong Exp $ Author: Che Dong
On Apache/1.3.41 (Unix) PHP/5.2.5 mod_perl/1.30 mod_gzip/1.3.26.1a
Under GNU General Public License
2008-08-31 00:38 @38.103.63.61 CrawledBy CCBot/1.0 (+http://www.commoncrawl.org/bot.html)