Go to the first, previous, next, last section, table of contents.
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
Automake also supplies some Autoconf macros to make the maintenance
easier. These macros can automatically be put into your
`aclocal.m4' using the
The simplest way to meet the basic Automake requirements is to use the
AM_INIT_AUTOMAKE (see section Autoconf macros supplied with Automake). But if you prefer, you
can do the required steps by hand:
PACKAGEshould be the name of the package as it appears when bundled for distribution. For instance, Automake defines
PACKAGEto be `automake'.
VERSIONshould be the version number of the release that is being developed. We recommend that you make `configure.in' the only place in your package where the version number is defined; this makes releases simpler. Automake doesn't do any interpretation of
VERSION, except in `Gnits' mode (see section The effect of
AC_ARG_PROGRAMif a program or script is installed. See section `Transforming Program Names When Installing' in The Autoconf.
AC_PROG_MAKE_SETif the package is not flat. See section `Creating Output Files' in The Autoconf Manual.
AM_SANITY_CHECKto make sure the build environment is sane.
AC_PROG_INSTALL(see section `Particular Program Checks' in The Autoconf Manual).
AM_MISSING_PROGto see whether the programs
makeinfoare in the build environment. Here is how this is done:
missing_dir=`cd $ac_aux_dir && pwd` AM_MISSING_PROG(ACLOCAL, aclocal, $missing_dir) AM_MISSING_PROG(AUTOCONF, autoconf, $missing_dir) AM_MISSING_PROG(AUTOMAKE, automake, $missing_dir) AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir) AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
Here are the other macros which Automake requires but which are not run
Makefileare 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
Automake will also recognize the use of certain macros and tailor the generated `Makefile.in' appropriately. Currently recognized macros and their effects are:
AM_CONFIG_HEADER, which is similar to
AC_CONFIG_HEADER(see section `Configuration Header Files' in The Autoconf Manual), but does some useful Automake-specific work.
AC_PATH_XTRAinto each `Makefile.in' that builds a C program or library. See section `System Services' in The Autoconf Manual.
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.
automake -awill not install the sources. See section Building a library, for more information. Also, see section `Particular Function Checks' in The Autoconf Manual.
LIBOBJS, and will treat these additional files as if they were discovered via
AC_REPLACE_FUNCS. See section `Generic Function Checks' in The Autoconf Manual.
libtool(see section `Introduction' in The Libtool Manual).
configure. If this is used,
automakewill 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
--gnits). This macro defines the `MAINTAINER_MODE' conditional, which you can use in your own `Makefile.am'.
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
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.
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:
aclocalwill 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.
strtodfunction is not available, or does not work correctly (like the one on SunOS 5.4), add `strtod.o' to output variable
error_at_lineis not found, then add `error.o' to
mktimefunction. If not found, add `mktime.o' to `LIBOBJS'.
TIOCGWINSZrequires `<sys/ioctl.h>', then define
TIOCGWINSZcan be found in `<termios.h>'.
AC_DEFINE's `PACKAGE' and `VERSION'. This can be avoided by passing in a non-empty third argument.
emacs, and, if found, sets the output variable
lispdirto the full path to Emacs' site-lisp directory.
CCto 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_stdcis set to `no'. If you wrote your source code in ANSI C, you can make an un-ANSIfied copy of it by using the
ansi2knroption (see section Automatic de-ANSI-fication).
AC_DECL_YYTEXT(see section `Particular Program Checks' in The Autoconf Manual), but uses the
missingscript on systems that do not have
lex. `HP-UX 10' is one such system.
am_cv_sys_posix_termiosto `yes'. If not, set the variable to `no'.
WITH_DMALLOCand add `-ldmalloc' to
configurecommand 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'.
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
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
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 `$(datadir)/aclocal'.
Go to the first, previous, next, last section, table of contents.