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