Go to the first, previous, next, last section, table of contents.

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.

Configuration requirements

The simplest way to meet the basic Automake requirements is to use the macro AM_INIT_AUTOMAKE (see section Autoconf macros supplied with Automake). But if you prefer, you can do the required steps by hand:

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

Automake uses this to determine which files to create. Listed files named Makefile are treated as `Makefile's. Other listed files are treated differently. Currently the only difference is that a `Makefile' is removed by make distclean, while other files are removed by make clean.

Other things Automake recognizes

Automake will also recognize the use of certain macros and tailor the generated `Makefile.in' appropriately. Currently recognized macros and their effects are:

Automake requires the use of AM_CONFIG_HEADER, which is similar to AC_CONFIG_HEADER but does some useful Automake-specific work.
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). FIXME: give complete list of things looked for in this directory
Automake will insert definitions for the variables defined by AC_PATH_XTRA into each `Makefile.in' that builds a C program or library.
Automake will ensure that `config.guess' and `config.sub' exist. Also, the `Makefile' variables `host_alias' and `host_triplet' are introduced.
This is similar to AC_CANONICAL_HOST, but also defines the `Makefile' variables `build_alias' and `target_alias'.
Automake will ensure that the appropriate dependencies are generated for the objects corresponding to these macros. Also, Automake will verify that the appropriate source files are part of the distribution. Note that Automake does not come with any of the C sources required to use these macros, so automake -a will not install the sources. See section Building a library for more information.
Automake will detect statements which put `.o' files into LIBOBJS, and will treat these additional files as if they were discovered via AC_REPLACE_FUNCS.
This is required if any libraries are built in the package.
This is required if any C++ source is included.
Automake will turn on processing for libtool (see section `The Libtool Manual' in The Libtool Manual).
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.
This macro is required if there is Lex source in the package.
If a Lex source file is seen, then this macro must be used.
If Automake sees that this variable is set in `configure.in', it will check the `po' directory to ensure that all the named `.po' files exist, and that all the `.po' files that exist are named.
This is required when using automatic de-ANSI-fication, see section Automatic de-ANSI-fication.
This macro is required for packages which use GNU gettext (see section Gettext). It is distributed with gettext. If Automake sees this macro it ensures that the package meets some of gettext's requirements.
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 is disallowed in `Gnits' mode (see section The effect of --gnu and --gnits).
For each of these macros, the first argument is automatically defined as a variable in each generated `Makefile.in'.

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 is extensible for use by other packages.

At startup, aclocal scans all the `.m4' files it can find, looking for macro definitions. 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 accepts the following options:

Look for the macro files in dir instead of the installation directory. This is typically used for debugging.
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.
Cause the output to be put into file instead of `aclocal.m4'.
Prints the name of the directory which aclocal will search to find the `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.
Print the names of the files it examines.
Print the version number of Automake and exit.

Autoconf macros supplied with Automake

Automake will generate rules to automatically regenerate the config header. If you do use this macro, you must create the file `stamp-h.in' in your source directory. It can be empty.
Check to see if this configure is being run in the `Cygwin32' environment. (FIXME xref). If so, define output variable EXEEXT to `.exe'; otherwise define it to the empty string. Automake recognizes this macro and uses it to generate `Makefile.in's which will automatically work under `Cygwin32'. In the `Cygwin32' environment, gcc generates executables whose names end in `.exe', even if this was not specified on the command line. Automake adds special code to `Makefile.in' to gracefully deal with this.
If the strtod function is not available, or does not work correctly (like the one on SunOS 5.4), add `strtod.o' to output variable LIBOBJS.
If the function error_at_line is not found, then add `error.o' to LIBOBJS.
Check for a working mktime function. If not found, add `mktime.o' to `LIBOBJS'.
Check for the GNU obstacks code; if not found, add `obstack.o' to `LIBOBJS'.
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.
If the use of TIOCGWINSZ requires `<sys/ioctl.h>', then define GWINSZ_IN_SYS_IOCTL. Otherwise TIOCGWINSZ can be found in `<termios.h>'.
Runs many macros that most `configure.in''s need. This macro has two required arguments, the package and the version number. By default this macro AC_DEFINE's `PACKAGE' and `VERSION'. This can be avoided by passing in a non-empty third argument.
Searches for the program emacs, and, if found, sets the output variable lispdir to the full path to Emacs' site-lisp directory.
If the C compiler in 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.
Like AC_PROG_INSTALL, but also defines INSTALL_SCRIPT.
Like AC_PROG_LEX with AC_DECL_YYTEXT, but uses the missing script on systems that do not have lex. `HP-UX 10' is one such system.
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.
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'.
Define `HAVE_PTRDIFF_T' if the type `ptrdiff_t' is defined in `<stddef.h>'.
Add support for the dmalloc package. If the user configures with `--with-dmalloc', then define WITH_DMALLOC and add `-ldmalloc' to LIBS. The dmalloc package can be found at ftp://ftp.letters.com/src/dmalloc/dmalloc.tar.gz
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'.

Writing your own aclocal macros

Aclocal 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. Aclocal also understands AC_REQUIRE, so it is safe to put each macro in a separate file.

A macro file's name should end in `.m4'. Such files should be installed in `$(datadir)/aclocal'.

Go to the first, previous, next, last section, table of contents.