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.