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.
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:
PACKAGE and VERSION with
AC_SUBST.
PACKAGE should be the name of the package as it appears when
bundled for distribution.  For instance, Automake defines PACKAGE
to be `automake'.  VERSION should 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 PACKAGE or
VERSION, except in `Gnits' mode (see section The effect of --gnu and --gnits).
AC_ARG_PROGRAM if a program or script is installed.
AC_PROG_MAKE_SET if the package is not flat.
AM_SANITY_CHECK to make sure the build environment is sane.
AM_PROG_INSTALL if any scripts (see section Executable Scripts) are
installed by the package.  Otherwise, use AC_PROG_INSTALL.
AM_MISSING_PROG to see whether the programs aclocal,
autoconf, automake, autoheader, and makeinfo
are 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
by AM_INIT_AUTOMAKE:
AC_OUTPUT
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.
Automake will also recognize the use of certain macros and tailor the generated `Makefile.in' appropriately. Currently recognized macros and their effects are:
AC_CONFIG_HEADER
AM_CONFIG_HEADER, which is similar
to AC_CONFIG_HEADER but does some useful Automake-specific work.
AC_CONFIG_AUX_DIR
AC_PATH_XTRA
AC_PATH_XTRA into each `Makefile.in' that builds a C program
or library.
AC_CANONICAL_HOST
AC_CHECK_TOOL
AC_CANONICAL_SYSTEM
AC_CANONICAL_HOST, but also defines the
`Makefile' variables `build_alias' and `target_alias'.
AC_FUNC_ALLOCA
AC_FUNC_GETLOADAVG
AC_FUNC_MEMCMP
AC_STRUCT_ST_BLOCKS
AC_FUNC_FNMATCH
AM_FUNC_STRTOD
AC_REPLACE_FUNCS
AC_REPLACE_GNU_GETOPT
AM_WITH_REGEX
automake -a will not install the sources.
See section Building a library for more information.
LIBOBJS
LIBOBJS, and will treat these additional files as if they were
discovered via AC_REPLACE_FUNCS.
AC_PROG_RANLIB
AC_PROG_CXX
AM_PROG_LIBTOOL
libtool (see section `The Libtool Manual' in The Libtool Manual).
AC_PROG_YACC
AC_DECL_YYTEXT
AC_PROG_LEX
ALL_LINGUAS
AM_C_PROTOTYPES
AM_GNU_GETTEXT
AM_MAINTAINER_MODE
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).
AC_SUBST
AC_CHECK_TOOL
AC_CHECK_PROG
AC_CHECK_PROGS
AC_PATH_PROG
AC_PATH_PROGS
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:
--acdir=dir
--help
-I dir
--output=file
--print-ac-dir
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.
--verbose
--version
AM_CONFIG_HEADER
AM_CYGWIN32
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.
AM_FUNC_STRTOD
strtod function is not available, or does not work
correctly (like the one on SunOS 5.4), add `strtod.o' to output
variable LIBOBJS.
AM_FUNC_ERROR_AT_LINE
error_at_line is not found, then add
`error.o' to LIBOBJS.
AM_FUNC_MKTIME
mktime function.  If not found, add
`mktime.o' to `LIBOBJS'.
AM_FUNC_OBSTACK
AM_C_PROTOTYPES
AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL
TIOCGWINSZ requires `<sys/ioctl.h>', then
define GWINSZ_IN_SYS_IOCTL.  Otherwise TIOCGWINSZ can be
found in `<termios.h>'.
AM_INIT_AUTOMAKE
AC_DEFINE's `PACKAGE' and `VERSION'.  This
can be avoided by passing in a non-empty third argument.
AM_PATH_LISPDIR
emacs, and, if found, sets the output
variable lispdir to the full path to Emacs' site-lisp directory.
AM_PROG_CC_STDC
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.
AM_PROG_INSTALL
AC_PROG_INSTALL, but also defines INSTALL_SCRIPT.
AM_PROG_LEX
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.
AM_SANITY_CHECK
AM_INIT_AUTOMAKE.
AM_SYS_POSIX_TERMIOS
am_cv_sys_posix_termios to
`yes'.  If not, set the variable to `no'.
AM_TYPE_PTRDIFF_T
AM_WITH_DMALLOC
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
AM_WITH_REGEX
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'.
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.