File: autoconf.info,  Node: Configuration Actions,  Next: Configuration Files,  Prev: Output,  Up: Setup

4.6 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_ITEMS(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

          AS_IF([...], [my_foos="$my_foos fooo"])
          AS_IF([...], [my_foos="$my_foos foooo"])
          AC_CONFIG_ITEMS([$my_foos])

     and use this instead:

          AS_IF([...], [AC_CONFIG_ITEMS([fooo])])
          AS_IF([...], [AC_CONFIG_ITEMS([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 *note 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.  Input files should be text files, and a line length
     below 2000 bytes should be safe.

COMMANDS
     Shell commands output literally into ‘config.status’, and
     associated with a tag that the user can use to tell ‘config.status’
     which 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 pre-computed:

     ‘srcdir’
          The name of the top source directory, assuming that the
          working directory is the top build directory.  This is what
          ‘configure’'s ‘--srcdir’ option 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.

     ‘tmp’
          The name of a temporary directory within the build tree, which
          you can use if you need to create additional temporary files.
          The directory is cleaned up when ‘config.status’ is done or
          interrupted.  Please use package-specific file name prefixes
          to avoid clashing with files that ‘config.status’ may use
          internally.

     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!