15 Rebuilding Makefiles

Automake generates rules to automatically rebuild Makefiles, configure, and other derived files like Makefile.in.

If you are using AM_MAINTAINER_MODE in configure.ac, then these automatic rebuilding rules are only enabled in maintainer mode.

Sometimes you need to run aclocal with an argument like -I to tell it where to find .m4 files. Since sometimes make will automatically run aclocal, you need a way to specify these arguments. You can do this by defining ACLOCAL_AMFLAGS; this holds arguments which are passed verbatim to aclocal. This variable is only useful in the top-level Makefile.am.

Sometimes it is convenient to supplement the rebuild rules for configure or config.status with additional dependencies. The variables CONFIGURE_DEPENDENCIES and CONFIG_STATUS_DEPENDENCIES can be used to list these extra dependencies. These variable should be defined in all Makefiles of the tree (because these two rebuild rules are output in all them), so it is safer and easier to AC_SUBST them from configure.ac. For instance the following statement will cause configure to be rerun each time version.sh is changed.

AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ['$(top_srcdir)/version.sh'])

Note the $(top_srcdir)/ in the filename. Since this variable is to be used in all Makefiles, its value must be sensible at any level in the build hierarchy.

Beware not to mistake CONFIGURE_DEPENDENCIES for CONFIG_STATUS_DEPENDENCIES.

CONFIGURE_DEPENDENCIES adds dependencies to the configure rule, whose effect is to run autoconf. This variable should be seldom used, because automake already tracks m4_included files. However it can be useful when playing tricky games with m4_esyscmd or similar non-recommendable macros with side effects.

CONFIG_STATUS_DEPENDENCIES adds dependencies to the config.status rule, whose effect is to run configure. This variable should therefore carry any non-standard source that may be read as a side effect of running configure, like version.sh in the example above.

Speaking of version.sh scripts, we recommend against them today. They are mainly used when the version of a package is updated automatically by a script (e.g., in daily builds). Here is what some old-style configure.acs may look like:

AC_INIT
. $srcdir/version.sh
AM_INIT_AUTOMAKE([name], $VERSION_NUMBER)
…

Here, version.sh is a shell fragment that sets VERSION_NUMBER. The problem with this example is that automake cannot track dependencies (listing version.sh in CONFIG_STATUS_DEPENDENCIES, and distributing this file is up to the user), and that it uses the obsolete form of AC_INIT and AM_INIT_AUTOMAKE. Upgrading to the new syntax is not straightforward, because shell variables are not allowed in AC_INIT’s arguments. We recommend that version.sh be replaced by an M4 file that is included by configure.ac:

m4_include([version.m4])
AC_INIT([name], VERSION_NUMBER)
AM_INIT_AUTOMAKE
…

Here version.m4 could contain something like m4_define([VERSION_NUMBER], [1.2]). The advantage of this second form is that automake will take care of the dependencies when defining the rebuild rule, and will also distribute the file automatically. An inconvenience is that autoconf will now be rerun each time the version number is bumped, when only configure had to be rerun in the previous setup.