5. Scanning `configure.in'

Automake scans the package's `configure.in' to determine certain information about the package. Some autoconf macros are required and some variables must be defined in `configure.in'. Automake will also use information from `configure.in' to further tailor its output.

Automake also supplies some Autoconf macros to make the maintenance easier. These macros can automatically be put into your `aclocal.m4' using the aclocal program.

5.1 Configuration requirements
5.2 Other things Automake recognizes
5.3 Auto-generating aclocal.m4
5.4 aclocal options		aclocal command line arguments
5.5 Macro search path		Modifying aclocal's search path
5.6 Autoconf macros supplied with Automake
5.7 Writing your own aclocal macros

5.1 Configuration requirements

The one real requirement of Automake is that your `configure.in' call AM_INIT_AUTOMAKE. This macro does several things which are required for proper Automake operation (see section 5.6 Autoconf macros supplied with Automake).

Here are the other macros which Automake requires but which are not run by AM_INIT_AUTOMAKE:

AC_CONFIG_FILES

AC_OUTPUT

Automake uses these to determine which files to create (see section `Creating Output Files' in The Autoconf Manual). A listed file is considered to be an Automake generated `Makefile' if there exists a file with the same name and the `.am' extension appended. Typically, AC_CONFIG_FILES([foo/Makefile]) will cause Automake to generate `foo/Makefile.in' if `foo/Makefile.am' exists.

Other listed files are treated differently. Currently the only difference is that an Automake `Makefile' is removed by make distclean, while other files are removed by make clean.

5.2 Other things Automake recognizes

Every time Automake is run it calls Autoconf to trace `configure.in'. This way it can recognize the use of certain macros and tailor the generated `Makefile.in' appropriately. Currently recognized macros and their effects are:

AC_CONFIG_HEADERS

Automake will generate rules to rebuild these headers. Older versions of Automake required the use of AM_CONFIG_HEADER (see section 5.6 Autoconf macros supplied with Automake); this is no longer the case today.

AC_CONFIG_AUX_DIR

Automake will look for various helper scripts, such as `mkinstalldirs', in the directory named in this macro invocation. If not seen, the scripts are looked for in their `standard' locations (either the top source directory, or in the source directory corresponding to the current `Makefile.am', whichever is appropriate). See section `Finding `configure' Input' in The Autoconf Manual. FIXME: give complete list of things looked for in this directory

AC_CANONICAL_HOST

Automake will ensure that `config.guess' and `config.sub' exist. Also, the `Makefile' variables `host_alias' and `host_triplet' are introduced. See section `Getting the Canonical System Type' in The Autoconf Manual.

AC_CANONICAL_SYSTEM

This is similar to AC_CANONICAL_HOST, but also defines the `Makefile' variables `build_alias' and `target_alias'. See section `Getting the Canonical System Type' in The Autoconf Manual.

AC_LIBSOURCE

AC_LIBSOURCES

AC_LIBOBJ

Automake will automatically distribute any file listed in AC_LIBSOURCE or AC_LIBSOURCES.

Note that the AC_LIBOBJ macro calls AC_LIBSOURCE. So if an Autoconf macro is documented to call AC_LIBOBJ([file]), then `file.c' will be distributed automatically by Automake. This encompasses many macros like AC_FUNC_ALLOCA, AC_FUNC_MEMCMP, AC_REPLACE_FUNCS, and others.

By the way, direct assignments to LIBOBJS are no longer supported. You should always use AC_LIBOBJ for this purpose. See section `AC_LIBOBJ vs. LIBOBJS' in The Autoconf Manual.

AC_PROG_RANLIB

This is required if any libraries are built in the package. See section `Particular Program Checks' in The Autoconf Manual.

AC_PROG_CXX

This is required if any C++ source is included. See section `Particular Program Checks' in The Autoconf Manual.

AC_PROG_F77

This is required if any Fortran 77 source is included. This macro is distributed with Autoconf version 2.13 and later. See section `Particular Program Checks' in The Autoconf Manual.

AC_F77_LIBRARY_LDFLAGS

This is required for programs and shared libraries that are a mixture of languages that include Fortran 77 (see section 9.10.3 Mixing Fortran 77 With C and C++). See section Autoconf macros supplied with Automake.

AC_PROG_LIBTOOL

Automake will turn on processing for libtool (see section `Introduction' in The Libtool Manual).

AC_PROG_YACC

If a Yacc source file is seen, then you must either use this macro or define the variable `YACC' in `configure.in'. The former is preferred (see section `Particular Program Checks' in The Autoconf Manual).

AC_PROG_LEX

If a Lex source file is seen, then this macro must be used. See section `Particular Program Checks' in The Autoconf Manual.

AC_SUBST

The first argument is automatically defined as a variable in each generated `Makefile.in'. See section `Setting Output Variables' in The Autoconf Manual.

If the Autoconf manual says that a macro calls AC_SUBST for var, or defined the output variable var then var will be defined in each generated `Makefile.in'. E.g. AC_PATH_XTRA defines X_CFLAGS and X_LIBS, so you can use the variable in any `Makefile.am' if AC_PATH_XTRA is called.

AM_C_PROTOTYPES

This is required when using automatic de-ANSI-fication; see 9.13 Automatic de-ANSI-fication.

AM_GNU_GETTEXT

This macro is required for packages which use GNU gettext (see section 11.2 Gettext). It is distributed with gettext. If Automake sees this macro it ensures that the package meets some of gettext's requirements.

AM_MAINTAINER_MODE

This macro adds a `--enable-maintainer-mode' option to configure. If this is used, automake will cause `maintainer-only' rules to be turned off by default in the generated `Makefile.in's. This macro defines the `MAINTAINER_MODE' conditional, which you can use in your own `Makefile.am'.

5.3 Auto-generating aclocal.m4

Automake includes a number of Autoconf macros which can be used in your package; some of them are actually required by Automake in certain situations. These macros must be defined in your `aclocal.m4'; otherwise they will not be seen by autoconf.

The aclocal program will automatically generate `aclocal.m4' files based on the contents of `configure.in'. This provides a convenient way to get Automake-provided macros, without having to search around. Also, the aclocal mechanism allows other packages to supply their own macros.

At startup, aclocal scans all the `.m4' files it can find, looking for macro definitions (see section 5.5 Macro search path). Then it scans `configure.in'. Any mention of one of the macros found in the first step causes that macro, and any macros it in turn requires, to be put into `aclocal.m4'.

The contents of `acinclude.m4', if it exists, are also automatically included in `aclocal.m4'. This is useful for incorporating local macros into `configure'.

aclocal tries to be smart about looking for new AC_DEFUNs in the files it scans. It also tries to copy the full text of the scanned file into `aclocal.m4', including both `#' and `dnl' comments. If you want to make a comment which will be completely ignored by aclocal, use `##' as the comment leader.

5.4 aclocal options		Options supported by aclocal
5.5 Macro search path		How aclocal finds .m4 files

5.4 aclocal options

aclocal accepts the following options:

--acdir=dir

Look for the macro files in dir instead of the installation directory. This is typically used for debugging.

--help

Print a summary of the command line options and exit.

-I dir

Add the directory dir to the list of directories searched for `.m4' files.

--output=file

Cause the output to be put into file instead of `aclocal.m4'.

--print-ac-dir

Prints the name of the directory which aclocal will search to find third-party `.m4' files. When this option is given, normal processing is suppressed. This option can be used by a package to determine where to install a macro file.

--verbose

Print the names of the files it examines.

--version

Print the version number of Automake and exit.

5.5 Macro search path

By default, aclocal searches for `.m4' files in the following directories, in this order:

acdir-APIVERSION

This is where the `.m4' macros distributed with automake itself are stored. APIVERSION depends on the automake release used; for automake 1.6.x, APIVERSION = 1.6.

acdir

This directory is intended for third party `.m4' files, and is configured when automake itself is built. This is `@datadir@/aclocal/', which typically expands to `${prefix}/share/aclocal/'. To find the compiled-in value of acdir, use the --print-ac-dir option (see section 5.4 aclocal options).

As an example, suppose that automake-1.6.2 was configured with --prefix=/usr/local. Then, the search path would be:

1. `/usr/local/share/aclocal-1.6/'
2. `/usr/local/share/aclocal/'

As explained in (see section 5.4 aclocal options), there are several options that can be used to change or extend this search path.

5.5.1 Modifying the macro search path: --acdir

The most obvious option to modify the search path is --acdir=dir, which changes default directory and drops the APIVERSION directory. For example, if one specifies --acdir=/opt/private/, then the search path becomes:

1. `/opt/private/'

Note that this option, --acdir, is intended for use by the internal automake test suite only; it is not ordinarily needed by end-users.

5.5.2 Modifying the macro search path: -I dir

Any extra directories specified using -I options (see section 5.4 aclocal options) are prepended to this search list. Thus, aclocal -I /foo -I /bar results in the following search path:

1. `/foo'
2. `/bar'
3. acdir-APIVERSION
4. acdir

5.5.3 Modifying the macro search path: `dirlist'

There is a third mechanism for customizing the search path. If a `dirlist' file exists in acdir, then that file is assumed to contain a list of directories, one per line, to be added to the search list. These directories are searched after all other directories.

For example, suppose `acdir/dirlist' contains the following:

/test1 /test2

and that aclocal was called with the -I /foo -I /bar options. Then, the search path would be

1. `/foo'
2. `/bar'
3. acdir-APIVERSION
4. acdir
5. `/test1'
6. `/test2'

If the --acdir=dir option is used, then aclocal will search for the `dirlist' file in dir. In the --acdir=/opt/private/ example above, aclocal would look for `/opt/private/dirlist'. Again, however, the --acdir option is intended for use by the internal automake test suite only; --acdir is not ordinarily needed by end-users.

`dirlist' is useful in the following situation: suppose that automake version 1.6.2 is installed with $prefix=/usr by the system vendor. Thus, the default search directories are

1. `/usr/share/aclocal-1.6/'
2. `/usr/share/aclocal/'

However, suppose further that many packages have been manually installed on the system, with $prefix=/usr/local, as is typical. In that case, many of these "extra" `.m4' files are in `/usr/local/share/aclocal'. The only way to force `/usr/bin/aclocal' to find these "extra" `.m4' files is to always call aclocal -I /usr/local/share/aclocal. This is inconvenient. With `dirlist', one may create the file

`/usr/share/aclocal/dirlist'

which contains only the single line

`/usr/local/share/aclocal'

Now, the "default" search path on the affected system is

1. `/usr/share/aclocal-1.6/'
2. `/usr/share/aclocal/'
3. `/usr/local/share/aclocal/'

without the need for -I options; -I options can be reserved for project-specific needs (`my-source-dir/m4/'), rather than using it to work around local system-dependent tool installation directories.

Similarly, `dirlist' can be handy if you have installed a local copy Automake on your account and want aclocal to look for macros installed at other places on the system.

5.6 Autoconf macros supplied with Automake

Automake ships with several Autoconf macros that you can use from your `configure.in'. When you use one of them it will be included by aclocal in `aclocal.m4'.

5.6.1 Public macros		Macros that you can use.
5.6.2 Private macros		Macros that you should not use.

5.6.1 Public macros

AM_CONFIG_HEADER

Automake will generate rules to automatically regenerate the config header. This obsolete macro is a synonym of AC_CONFIG_HEADERS today (see section 5.2 Other things Automake recognizes).

AM_ENABLE_MULTILIB

This is used when a "multilib" library is being built. The first optional argument is the name of the `Makefile' being generated; it defaults to `Makefile'. The second option argument is used to find the top source directory; it defaults to the empty string (generally this should not be used unless you are familiar with the internals). See section 18.3 Support for Multilibs.

AM_C_PROTOTYPES

Check to see if function prototypes are understood by the compiler. If so, define `PROTOTYPES' and set the output variables `U' and `ANSI2KNR' to the empty string. Otherwise, set `U' to `_' and `ANSI2KNR' to `./ansi2knr'. Automake uses these values to implement automatic de-ANSI-fication.

AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL

If the use of TIOCGWINSZ requires `<sys/ioctl.h>', then define GWINSZ_IN_SYS_IOCTL. Otherwise TIOCGWINSZ can be found in `<termios.h>'.

AM_INIT_AUTOMAKE([OPTIONS])

AM_INIT_AUTOMAKE(PACKAGE, VERSION, [NO-DEFINE])

Runs many macros required for proper operation of the generated Makefiles.

This macro has two forms, the second of which has two required arguments: the package and the version number. This latter form is obsolete because the package and version can be obtained from Autoconf's AC_INIT macro (which itself has an old and a new form).

If your `configure.in' has:

AC_INIT(src/foo.c) AM_INIT_AUTOMAKE(mumble, 1.5)

you can modernize it as follow:

AC_INIT(mumble, 1.5) AC_CONFIG_SRCDIR(src/foo.c) AM_INIT_AUTOMAKE

Note that if you're upgrading your `configure.in' from an earlier version of Automake, it is not always correct to simply move the package and version arguments from AM_INIT_AUTOMAKE directly to AC_INIT, as in the example above. The first argument of AC_INIT is the name of your package (e.g. `GNU Automake'), not the tarball name (e.g. `automake') you used to pass to AM_INIT_AUTOMAKE. Autoconf's rule to derive a tarball name from the package name should work for most but not all packages. Especially, if your tarball name is not all lower case, you will have to use the four-argument form of AC_INIT (supported in Autoconf versions greater than 2.52g).

When AM_INIT_AUTOMAKE is called with a single argument, it is interpreted as a space-separated list of Automake options which should be applied to every `Makefile.am' in the tree. The effect is as if each option were listed in AUTOMAKE_OPTIONS.

By default this macro AC_DEFINE's `PACKAGE' and `VERSION'. This can be avoided by passing the `no-define' option, as in:

AM_INIT_AUTOMAKE([gnits 1.5 no-define dist-bzip2])

or by passing a third non-empty argument to the obsolete form.

AM_PATH_LISPDIR

Searches for the program emacs, and, if found, sets the output variable lispdir to the full path to Emacs' site-lisp directory.

Note that this test assumes the emacs found to be a version that supports Emacs Lisp (such as GNU Emacs or XEmacs). Other emacsen can cause this test to hang (some, like old versions of MicroEmacs, start up in interactive mode, requiring `C-x C-c' to exit, which is hardly obvious for a non-emacs user). In most cases, however, you should be able to use `C-c' to kill the test. In order to avoid problems, you can set EMACS to "no" in the environment, or use the `--with-lispdir' option to configure to explictly set the correct path (if you're sure you have an emacs that supports Emacs Lisp.

AM_PROG_AS

Use this macro when you have assembly code in your project. This will choose the assembler for you (by default the C compiler) and set CCAS, and will also set CCASFLAGS if required.

AM_PROG_CC_C_O

This is like AC_PROG_CC_C_O, but it generates its results in the manner required by automake. You must use this instead of AC_PROG_CC_C_O when you need this functionality.

AM_PROG_CC_STDC

If the C compiler is not in ANSI C mode by default, try to add an option to output variable CC to make it so. This macro tries various options that select ANSI C on some system or another. It considers the compiler to be in ANSI C mode if it handles function prototypes correctly.

If you use this macro, you should check after calling it whether the C compiler has been set to accept ANSI C; if not, the shell variable am_cv_prog_cc_stdc is set to `no'. If you wrote your source code in ANSI C, you can make an un-ANSIfied copy of it by using the ansi2knr option (see section 9.13 Automatic de-ANSI-fication).

This macro is a relic from the time Autoconf didn't offer such a feature. AM_PROG_CC_STDC's logic has now been merged into Autoconf's AC_PROG_CC macro, therefore you should use the latter instead. Chances are you are already using AC_PROG_CC, so you can simply remove the AM_PROG_CC_STDC call and turn all occurrences of $am_cv_prog_cc_stdc into $ac_cv_prog_cc_stdc. AM_PROG_CC_STDC will be marked as obsolete (in the Autoconf sense) in Automake 1.8.

AM_PROG_LEX

Like AC_PROG_LEX (see section `Particular Program Checks' in The Autoconf Manual), but uses the missing script on systems that do not have lex. `HP-UX 10' is one such system.

AM_PROG_GCJ

This macro finds the gcj program or causes an error. It sets `GCJ' and `GCJFLAGS'. gcj is the Java front-end to the GNU Compiler Collection.

AM_SYS_POSIX_TERMIOS

Check to see if POSIX termios headers and functions are available on the system. If so, set the shell variable am_cv_sys_posix_termios to `yes'. If not, set the variable to `no'.

AM_WITH_DMALLOC

Add support for the dmalloc package. If the user configures with `--with-dmalloc', then define WITH_DMALLOC and add `-ldmalloc' to LIBS.

AM_WITH_REGEX

Adds `--with-regex' to the configure command line. If specified (the default), then the `regex' regular expression library is used, `regex.o' is put into `LIBOBJS', and `WITH_REGEX' is defined. If `--without-regex' is given, then the `rx' regular expression library is used, and `rx.o' is put into `LIBOBJS'.

5.6.2 Private macros

The following macros are private macros you should not call directly. They are called by the other public macros when appropriate. Do not rely on them, as they might be changed in a future version. Consider them as implementation details; or better, do not consider them at all: skip this section!

_AM_DEPENDENCIES

AM_SET_DEPDIR

AM_DEP_TRACK

AM_OUTPUT_DEPENDENCY_COMMANDS

These macros are used to implement automake's automatic dependency tracking scheme. They are called automatically by automake when required, and there should be no need to invoke them manually.

AM_MAKE_INCLUDE

This macro is used to discover how the user's make handles include statements. This macro is automatically invoked when needed; there should be no need to invoke it manually.

AM_PROG_INSTALL_STRIP

This is used to find a version of install which can be used to strip a program at installation time. This macro is automatically included when required.

AM_SANITY_CHECK

This checks to make sure that a file created in the build directory is newer than a file in the source directory. This can fail on systems where the clock is set incorrectly. This macro is automatically run from AM_INIT_AUTOMAKE.

5.7 Writing your own aclocal macros

The aclocal program doesn't have any built-in knowledge of any macros, so it is easy to extend it with your own macros.

This is mostly used for libraries which want to supply their own Autoconf macros for use by other programs. For instance the gettext library supplies a macro AM_GNU_GETTEXT which should be used by any package using gettext. When the library is installed, it installs this macro so that aclocal will find it.

A file of macros should be a series of AC_DEFUN's. The aclocal programs also understands AC_REQUIRE, so it is safe to put each macro in a separate file. See section `Prerequisite Macros' in The Autoconf Manual, and section `Macro Definitions' in The Autoconf Manual.

A macro file's name should end in `.m4'. Such files should be installed in `aclocal --print-ac-dir` (which usually happens to be `$(datadir)/aclocal').