autoconf.info: config.status Invocation

Go forward to Obsolete Constructs
Go backward to Running configure Scripts
Go up to Top
Go to the top op autoconf

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.