automake: Rebuilding

1 
1 16 Rebuilding Makefiles
1 ***********************
1 
1 Automake generates rules to automatically rebuild ‘Makefile’s,
1 ‘configure’, and other derived files like ‘Makefile.in’.
1 
1    If you are using ‘AM_MAINTAINER_MODE’ in ‘configure.ac’, then these
1 automatic rebuilding rules are only enabled in maintainer mode.
1 
1    Sometimes it is convenient to supplement the rebuild rules for
1 ‘configure’ or ‘config.status’ with additional dependencies.  The
1 variables ‘CONFIGURE_DEPENDENCIES’ and ‘CONFIG_STATUS_DEPENDENCIES’ can
1 be used to list these extra dependencies.  These variables should be
1 defined in all ‘Makefile’s of the tree (because these two rebuild rules
1 are output in all them), so it is safer and easier to ‘AC_SUBST’ them
1 from ‘configure.ac’.  For instance, the following statement will cause
1 ‘configure’ to be rerun each time ‘version.sh’ is changed.
1 
1      AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ['$(top_srcdir)/version.sh'])
1 
1 Note the ‘$(top_srcdir)/’ in the file name.  Since this variable is to
1 be used in all ‘Makefile’s, its value must be sensible at any level in
1 the build hierarchy.
1 
1    Beware not to mistake ‘CONFIGURE_DEPENDENCIES’ for
1 ‘CONFIG_STATUS_DEPENDENCIES’.
1 
1    ‘CONFIGURE_DEPENDENCIES’ adds dependencies to the ‘configure’ rule,
1 whose effect is to run ‘autoconf’.  This variable should be seldom used,
1 because ‘automake’ already tracks ‘m4_include’d files.  However it can
1 be useful when playing tricky games with ‘m4_esyscmd’ or similar
1 non-recommendable macros with side effects.  Be also aware that
11 interactions of this variable with the ⇒autom4te cache
 (autoconf)Autom4te Cache. are quite problematic and can cause subtle
1 breakage, so you might want to disable the cache if you want to use
1 ‘CONFIGURE_DEPENDENCIES’.
1 
1    ‘CONFIG_STATUS_DEPENDENCIES’ adds dependencies to the ‘config.status’
1 rule, whose effect is to run ‘configure’.  This variable should
1 therefore carry any non-standard source that may be read as a side
1 effect of running ‘configure’, like ‘version.sh’ in the example above.
1 
1    Speaking of ‘version.sh’ scripts, we recommend against them today.
1 They are mainly used when the version of a package is updated
1 automatically by a script (e.g., in daily builds).  Here is what some
1 old-style ‘configure.ac’s may look like:
1 
1      AC_INIT
1      . $srcdir/version.sh
1      AM_INIT_AUTOMAKE([name], $VERSION_NUMBER)
1      ...
1 
1 Here, ‘version.sh’ is a shell fragment that sets ‘VERSION_NUMBER’.  The
1 problem with this example is that ‘automake’ cannot track dependencies
1 (listing ‘version.sh’ in ‘CONFIG_STATUS_DEPENDENCIES’, and distributing
1 this file is up to the user), and that it uses the obsolete form of
1 ‘AC_INIT’ and ‘AM_INIT_AUTOMAKE’.  Upgrading to the new syntax is not
1 straightforward, because shell variables are not allowed in ‘AC_INIT’’s
1 arguments.  We recommend that ‘version.sh’ be replaced by an M4 file
1 that is included by ‘configure.ac’:
1 
1      m4_include([version.m4])
1      AC_INIT([name], VERSION_NUMBER)
1      AM_INIT_AUTOMAKE
1      ...
1 
1 Here ‘version.m4’ could contain something like
1 ‘m4_define([VERSION_NUMBER], [1.2])’.  The advantage of this second form
1 is that ‘automake’ will take care of the dependencies when defining the
1 rebuild rule, and will also distribute the file automatically.  An
1 inconvenience is that ‘autoconf’ will now be rerun each time the version
1 number is bumped, when only ‘configure’ had to be rerun in the previous
1 setup.
1