Automake does constrain a project in certain ways; for instance it
assumes that the project uses Autoconf (@pxref{Top, , Introduction,
autoconf, The Autoconf Manual}), and enforces certain restrictions on
-the @file{configure.in} contents@footnote{Autoconf 2.50 promotes
+the @file{configure.ac} contents@footnote{Older Autoconf versions used
+@file{configure.in}. Autoconf 2.50 and greater promotes
@file{configure.ac} over @file{configure.in}. The rest of this
-documentation will refer to @file{configure.in} as this use is not yet
-spread, but Automake supports @file{configure.ac} too.}.
+documentation will refer to @file{configure.ac}, but Automake also
+supports @file{configure.in} for backward compatibility.}.
@cindex Automake requirements
@cindex Requirements, Automake
@cindex Overriding make variables
Similarly, a variable defined in @file{Makefile.am} or @code{AC_SUBST}'ed
-from @file{configure.in} will override any definition of the variable that
+from @file{configure.ac} will override any definition of the variable that
@code{automake} would ordinarily create. This feature is more often
useful than the ability to override a target definition. Be warned that
many of the variables generated by @code{automake} are considered to be for
@cindex AM_INIT_AUTOMAKE, example use
-The first step is to update your @file{configure.in} to include the
+The first step is to update your @file{configure.ac} to include the
commands that @code{automake} needs. The way to do this is to add an
@code{AM_INIT_AUTOMAKE} call just after @code{AC_INIT}:
Now it is time to write your @file{Makefile.am} for @code{zardoz}.
Since @code{zardoz} is a user program, you want to install it where the
rest of the user programs go: @code{bindir}. Additionally,
-@code{zardoz} has some Texinfo documentation. Your @file{configure.in}
+@code{zardoz} has some Texinfo documentation. Your @file{configure.ac}
script uses @code{AC_REPLACE_FUNCS}, so you need to link against
@samp{$(LIBOBJS)}. So here's what you'd write:
two-liner. GNU Hello is internationalized, does option processing, and
has a manual and a test suite.
-@cindex configure.in, from GNU Hello
-@cindex GNU Hello, configure.in
-@cindex Hello, configure.in
+@cindex configure.ac, from GNU Hello
+@cindex GNU Hello, configure.ac
+@cindex Hello, configure.ac
-Here is the @file{configure.in} from GNU Hello.
+Here is the @file{configure.ac} from GNU Hello.
@strong{Please note:} The calls to @code{AC_INIT} and @code{AM_INIT_AUTOMAKE}
in this example use a deprecated syntax. For the current approach,
see the description of @code{AM_INIT_AUTOMAKE} in @ref{Public macros}.
@node Invoking Automake
@chapter Creating a @file{Makefile.in}
-@cindex Multiple configure.in files
+@cindex Multiple configure.ac files
@cindex Invoking Automake
@cindex Automake, invoking
To create all the @file{Makefile.in}s for a package, run the
@code{automake} program in the top level directory, with no arguments.
@code{automake} will automatically find each appropriate
-@file{Makefile.am} (by scanning @file{configure.in}; @pxref{configure})
+@file{Makefile.am} (by scanning @file{configure.ac}; @pxref{configure})
and generate the corresponding @file{Makefile.in}. Note that
@code{automake} has a rather simplistic view of what constitutes a
-package; it assumes that a package has only one @file{configure.in}, at
-the top. If your package has multiple @file{configure.in}s, then you
+package; it assumes that a package has only one @file{configure.ac}, at
+the top. If your package has multiple @file{configure.ac}s, then you
must run @code{automake} in each directory holding a
-@file{configure.in}. (Alternatively, you may rely on Autoconf's
+@file{configure.ac}. (Alternatively, you may rely on Autoconf's
@code{autoreconf}, which is able to recurse your package tree and run
@code{automake} where appropriate.)
out-of-date @file{Makefile.in}. Note that @code{automake} must always
be run from the topmost directory of a project, even if being used to
regenerate the @file{Makefile.in} in some subdirectory. This is
-necessary because @code{automake} must scan @file{configure.in}, and
+necessary because @code{automake} must scan @file{configure.ac}, and
because @code{automake} uses the knowledge that a @file{Makefile.in} is
in a subdirectory to change its behavior in some cases.
@vindex AUTOCONF
-Automake will run @code{autoconf} to scan @file{configure.in} and its
+Automake will run @code{autoconf} to scan @file{configure.ac} and its
dependencies (@file{aclocal.m4}), therefore @code{autoconf} must be in
your @code{PATH}. If there is an @code{AUTOCONF} variable in your
environment it will be used instead of @code{autoconf}, this allows you
to select a particular version of Autoconf. By the way, don't
misunderstand this paragraph: Automake runs @code{autoconf} to
-@strong{scan} your @file{configure.in}, this won't build
+@strong{scan} your @file{configure.ac}, this won't build
@file{configure} and you still have to run @code{autoconf} yourself for
this purpose.
@opindex -a
@opindex --add-missing
Automake requires certain common files to exist in certain situations;
-for instance @file{config.guess} is required if @file{configure.in} runs
+for instance @file{config.guess} is required if @file{configure.ac} runs
@code{AC_CANONICAL_HOST}. Automake is distributed with several of these
files (@pxref{Auxiliary Programs}); this option will cause the missing
ones to be automatically added to the package, whenever possible. In
@item --no-force
@opindex --no-force
Ordinarily @code{automake} creates all @file{Makefile.in}s mentioned in
-@file{configure.in}. This option causes it to only update those
+@file{configure.ac}. This option causes it to only update those
@file{Makefile.in}s which are out of date with respect to one of their
dependents.
@node configure
-@chapter Scanning @file{configure.in}
+@chapter Scanning @file{configure.ac}
-@cindex configure.in, scanning
-@cindex Scanning configure.in
+@cindex configure.ac, scanning
+@cindex Scanning configure.ac
-Automake scans the package's @file{configure.in} to determine certain
+Automake scans the package's @file{configure.ac} to determine certain
information about the package. Some @code{autoconf} macros are required
-and some variables must be defined in @file{configure.in}. Automake
-will also use information from @file{configure.in} to further tailor its
+and some variables must be defined in @file{configure.ac}. Automake
+will also use information from @file{configure.ac} to further tailor its
output.
Automake also supplies some Autoconf macros to make the maintenance
@cindex Automake requirements
@cindex Requirements of Automake
-The one real requirement of Automake is that your @file{configure.in}
+The one real requirement of Automake is that your @file{configure.ac}
call @code{AM_INIT_AUTOMAKE}. This macro does several things which are
required for proper Automake operation (@pxref{Macros}).
@cvindex AM_INIT_AUTOMAKE
@cindex Recognized macros by Automake
Every time Automake is run it calls Autoconf to trace
-@file{configure.in}. This way it can recognize the use of certain
+@file{configure.ac}. This way it can recognize the use of certain
macros and tailor the generated @file{Makefile.in} appropriately.
Currently recognized macros and their effects are:
@item AC_PROG_YACC
If a Yacc source file is seen, then you must either use this macro or
-define the variable @samp{YACC} in @file{configure.in}. The former is
+define the variable @samp{YACC} in @file{configure.ac}. The former is
preferred (@pxref{Particular Programs, , Particular Program Checks,
autoconf, The Autoconf Manual}).
@cvindex AC_PROG_YACC
@item m4_include
@cvindex m4_include
-Files included by @file{configure.in} using this macro will be
+Files included by @file{configure.ac} using this macro will be
detected by Automake and automatically distributed. They will also
appear as dependencies in @file{Makefile} rules.
-@code{m4_include} is seldom used by @file{configure.in} authors, but
+@code{m4_include} is seldom used by @file{configure.ac} authors, but
can appear in @file{aclocal.m4} when @command{aclocal} detects that
some required macros come from files local to your package (as
opposed to macros installed in a system-wide directory, see
@command{autoconf}.
The @command{aclocal} program will automatically generate
-@file{aclocal.m4} files based on the contents of @file{configure.in}.
+@file{aclocal.m4} files based on the contents of @file{configure.ac}.
This provides a convenient way to get Automake-provided macros,
without having to search around. The @command{aclocal} mechanism
allows other packages to supply their own macros (@pxref{Extending
At startup, @command{aclocal} scans all the @file{.m4} files it can
find, looking for macro definitions (@pxref{Macro search path}). Then
-it scans @file{configure.in}. Any mention of one of the macros found
+it scans @file{configure.ac}. 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 @file{aclocal.m4}.
@section Autoconf macros supplied with Automake
Automake ships with several Autoconf macros that you can use from your
-@file{configure.in}. When you use one of them it will be included by
+@file{configure.ac}. When you use one of them it will be included by
@code{aclocal} in @file{aclocal.m4}.
@menu
from Autoconf's @code{AC_INIT} macro (which itself has an old and a new
form).
-If your @file{configure.in} has:
+If your @file{configure.ac} has:
@example
AC_INIT(src/foo.c)
AM_INIT_AUTOMAKE(mumble, 1.5)
AM_INIT_AUTOMAKE
@end example
-Note that if you're upgrading your @file{configure.in} from an earlier
+Note that if you're upgrading your @file{configure.ac} from an earlier
version of Automake, it is not always correct to simply move the package
and version arguments from @code{AM_INIT_AUTOMAKE} directly to
@code{AC_INIT}, as in the example above. The first argument to
system-wide directories, as explained in @ref{Macro search path}.
Custom macros should be distributed for the same reason that
-@file{configure.in} is: so that other people have all the sources of
+@file{configure.ac} is: so that other people have all the sources of
your package if they want to work on it. Actually, this distribution
happens automatically because all @code{m4_include}d files are
distributed.
aclocal}). For instance Guile ships with a file called
@file{guile.m4} that contains the macro @code{GUILE_FLAGS} which can
be used to define setup compiler and linker flags appropriate for
-using Guile. Using @code{GUILE_FLAGS} in @file{configure.in} will
+using Guile. Using @code{GUILE_FLAGS} in @file{configure.ac} will
cause @command{aclocal} to copy @file{guile.m4} into
@file{aclocal.m4}, but as @file{guile.m4} is not part of the project,
it will not be distributed. Technically, that means a user which
Automake generates rules to automatically rebuild @file{Makefile}s,
@file{configure}, and other derived files like @file{Makefile.in}.
-If you are using @code{AM_MAINTAINER_MODE} in @file{configure.in}, then
+If you are using @code{AM_MAINTAINER_MODE} in @file{configure.ac}, then
these automatic rebuilding rules are only enabled in maintainer mode.
Sometimes you need to run @code{aclocal} with an argument like @code{-I}
@noindent
You can then setup the @code{$(HELLO_SYSTEM)} substitution from
-@file{configure.in}:
+@file{configure.ac}:
@example
@dots{}
endif
@end example
-In this case, your @file{configure.in} should setup the @code{LINUX}
+In this case, your @file{configure.ac} should setup the @code{LINUX}
conditional using @code{AM_CONDITIONAL} (@pxref{Conditionals}).
When using conditionals like this you don't need to use the
by invoking @code{$(AR) $(ARFLAGS)} followed by the name of the
library and the list of objects, and finally by calling
@code{$(RANLIB)} on that library. You should call
-@code{AC_PROG_RANLIB} from your @file{configure.in} to define
+@code{AC_PROG_RANLIB} from your @file{configure.ac} to define
@code{RANLIB} (Automake will complain otherwise). @code{AR} and
@code{ARFLAGS} default to @code{ar} and @code{cru} respectively; you
can override these two variables my setting them in your
@file{Makefile.am}, by @code{AC_SUBST}ing them from your
-@file{configure.in}, or by defining a per-library @code{maude_AR}
+@file{configure.ac}, or by defining a per-library @code{maude_AR}
variable (@pxref{Program and Library Variables}).
@node A Shared Library
@samp{-dlopen} and @samp{-dlpreopen}). Use the @samp{_LDFLAGS} variable
for this purpose.
-For instance, if your @file{configure.in} uses @code{AC_PATH_XTRA}, you
+For instance, if your @file{configure.ac} uses @code{AC_PATH_XTRA}, you
could link your program against the X libraries like so:
@example
Automake explicitly recognizes the use of @code{$(LIBOBJS)} and
@code{$(ALLOCA)}, and uses this information, plus the list of
-@code{LIBOBJS} files derived from @file{configure.in} to automatically
+@code{LIBOBJS} files derived from @file{configure.ac} to automatically
include the appropriate source files in the distribution (@pxref{Dist}).
These source files are also automatically handled in the
dependency-tracking scheme; see @xref{Dependencies}.
included in any distribution that is made. That way the user doesn't
need to have @code{yacc} or @code{lex}.
-If a @code{yacc} source file is seen, then your @file{configure.in} must
+If a @code{yacc} source file is seen, then your @file{configure.ac} must
define the variable @samp{YACC}. This is most easily done by invoking
the macro @samp{AC_PROG_YACC} (@pxref{Particular Programs, , Particular
Program Checks, autoconf, The Autoconf Manual}).
foo_SOURCES = @dots{} parser.y @dots{}
@end example
-If a @code{lex} source file is seen, then your @file{configure.in}
+If a @code{lex} source file is seen, then your @file{configure.ac}
must define the variable @samp{LEX}. You can use @samp{AC_PROG_LEX}
to do this (@pxref{Particular Programs, , Particular Program Checks,
autoconf, The Autoconf Manual}), but using @code{AM_PROG_LEX} macro
program is distributed with Automake. It should appear in the directory
specified by @samp{AC_CONFIG_AUX_DIR} (@pxref{Input, , Finding
`configure' Input, autoconf, The Autoconf Manual}), or the current
-directory if that macro is not used in @file{configure.in}.
+directory if that macro is not used in @file{configure.ac}.
For @code{yacc}, simply managing locking is insufficient. The output of
@code{yacc} always uses the same symbol names internally, so it isn't
Automake includes full support for C++.
Any package including C++ code must define the output variable
-@samp{CXX} in @file{configure.in}; the simplest way to do this is to use
+@samp{CXX} in @file{configure.ac}; the simplest way to do this is to use
the @code{AC_PROG_CXX} macro (@pxref{Particular Programs, , Particular
Program Checks, autoconf, The Autoconf Manual}).
@vindex CCASFLAGS
You are required to set @code{CCAS} and @code{CCASFLAGS} via
-@file{configure.in}. The autoconf macro @code{AM_PROG_AS} will do this
+@file{configure.ac}. The autoconf macro @code{AM_PROG_AS} will do this
for you. Unless they are already set, it simply sets @code{CCAS} to the
C compiler and @code{CCASFLAGS} to the C compiler flags.
Automake includes full support for Fortran 77.
Any package including Fortran 77 code must define the output variable
-@samp{F77} in @file{configure.in}; the simplest way to do this is to use
+@samp{F77} in @file{configure.ac}; the simplest way to do this is to use
the @code{AC_PROG_F77} macro (@pxref{Particular Programs, , Particular
Program Checks, autoconf, The Autoconf Manual}). @xref{Fortran 77 and
Autoconf}.
some @code{_PROGRAMS} or @code{_LTLIBRARIES} primary) contains source
code that is a mixture of Fortran 77 and C and/or C++, then it requires
that the macro @code{AC_F77_LIBRARY_LDFLAGS} be called in
-@file{configure.in}, and that either @code{$(FLIBS)}
+@file{configure.ac}, and that either @code{$(FLIBS)}
appear in the appropriate @code{_LDADD} (for programs) or @code{_LIBADD}
(for shared libraries) variables. It is the responsibility of the
person writing the @file{Makefile.am} to make sure that @code{$(FLIBS)}
@end example
In this case, Automake will insist that @code{AC_F77_LIBRARY_LDFLAGS}
-is mentioned in @file{configure.in}. Also, if @code{$(FLIBS)} hadn't
+is mentioned in @file{configure.ac}. Also, if @code{$(FLIBS)} hadn't
been mentioned in @code{foo_LDADD} and @code{libfoo_la_LIBADD}, then
Automake would have issued a warning.
front end to the GNU Compiler Collection.
Any package including Java code to be compiled must define the output
-variable @samp{GCJ} in @file{configure.in}; the variable @samp{GCJFLAGS}
-must also be defined somehow (either in @file{configure.in} or
+variable @samp{GCJ} in @file{configure.ac}; the variable @samp{GCJFLAGS}
+must also be defined somehow (either in @file{configure.ac} or
@file{Makefile.am}). The simplest way to do this is to use the
@code{AM_PROG_GCJ} macro.
Support for de-ANSI-fication requires the source files @file{ansi2knr.c}
and @file{ansi2knr.1} to be in the same package as the ANSI C source;
these files are distributed with Automake. Also, the package
-@file{configure.in} must call the macro @code{AM_C_PROTOTYPES}
+@file{configure.ac} must call the macro @code{AM_C_PROTOTYPES}
(@pxref{Macros}).
@cvindex AM_C_PROTOTYPES
However, Automake cannot apply this rewriting to @code{configure}
substitutions. This means that if you are conditionally building a
-program using such a substitution, then your @file{configure.in} must
+program using such a substitution, then your @file{configure.ac} must
take care to add @samp{$(EXEEXT)} when constructing the output variable.
With Autoconf 2.13 and earlier, you must explicitly use @code{AC_EXEEXT}
Automake provides some support for Emacs Lisp. The @samp{LISP} primary
is used to hold a list of @file{.el} files. Possible prefixes for this
primary are @samp{lisp_} and @samp{noinst_}. Note that if
-@code{lisp_LISP} is defined, then @file{configure.in} must run
+@code{lisp_LISP} is defined, then @file{configure.ac} must run
@code{AM_PATH_LISPDIR} (@pxref{Macros}).
Automake will byte-compile all Emacs Lisp source files using the Emacs
@cindex Gettext support
@cindex Support for GNU Gettext
-If @code{AM_GNU_GETTEXT} is seen in @file{configure.in}, then Automake
+If @code{AM_GNU_GETTEXT} is seen in @file{configure.ac}, then Automake
turns on support for GNU gettext, a message catalog system for
internationalization
(@pxref{GNU Gettext, , , gettext, GNU gettext utilities}).
Automake ships with an Autoconf macro called @code{AM_PATH_PYTHON} which
will determine some Python-related directory variables (see below). If
-you have called @code{AM_PATH_PYTHON} from @file{configure.in}, then you
+you have called @code{AM_PATH_PYTHON} from @file{configure.ac}, then you
may use the following variables to list you Python source files in your
variables: @samp{python_PYTHON}, @samp{pkgpython_PYTHON},
@samp{pyexecdir_PYTHON}, @samp{pkgpyexecdir_PYTHON}, depending where you
By default, Automake requires the file @file{texinfo.tex} to appear in
the same directory as the Texinfo source. However, if you used
-@code{AC_CONFIG_AUX_DIR} in @file{configure.in} (@pxref{Input, , Finding
+@code{AC_CONFIG_AUX_DIR} in @file{configure.ac} (@pxref{Input, , Finding
`configure' Input, autoconf, The Autoconf Manual}), then
@file{texinfo.tex} is looked for there. Automake supplies
@file{texinfo.tex} if @samp{--add-missing} is given.
(i.e. the source files corresponding to the files specified in various
Autoconf macros such as @code{AC_CONFIG_FILES} and siblings) are
automatically distributed. Files included in @file{Makefile.am}s (using
-@code{include}) or in @file{configure.in} (using @code{m4_include}), and
+@code{include}) or in @file{configure.ac} (using @code{m4_include}), and
helper scripts installed with @samp{automake --add-missing} are also
distributed.
basis when listed in a special @file{Makefile} variable named
@code{AUTOMAKE_OPTIONS}. They are applied globally to all processed
@file{Makefiles} when listed in the first argument of
-@code{AM_INIT_AUTOMAKE} in @file{configure.in}. Currently understood
+@code{AM_INIT_AUTOMAKE} in @file{configure.ac}. Currently understood
options are:
@vindex AUTOMAKE_OPTIONS
(@pxref{Invoking Automake}). This allows you to enable or disable some
warning categories on a per-file basis. You can also setup some warnings
for your entire project; for instance try @code{AM_INIT_AUTOMAKE([-Wall])}
-in your @file{configure.in}.
+in your @file{configure.ac}.
@end table
Unrecognized options are diagnosed by @code{automake}.
If you want an option to apply to all the files in the tree, you can use
-the @code{AM_INIT_AUTOMAKE} macro in @file{configure.in}.
+the @code{AM_INIT_AUTOMAKE} macro in @file{configure.ac}.
@xref{Macros}.
@cvindex AM_CONDITIONAL
Before using a conditional, you must define it by using
-@code{AM_CONDITIONAL} in the @code{configure.in} file (@pxref{Macros}).
+@code{AM_CONDITIONAL} in the @code{configure.ac} file (@pxref{Macros}).
@defmac AM_CONDITIONAL (@var{conditional}, @var{condition})
The conditional name, @var{conditional}, should be a simple string
@command{ln}). Ideally you should fall back to @code{cp -p} when
@code{ln} does not work. An easy way, if symbolic links are
acceptable to you, is to add @code{AC_PROG_LN_S} to
-@file{configure.in} (@pxref{Particular Programs, , Particular Program
+@file{configure.ac} (@pxref{Particular Programs, , Particular Program
Checks, autoconf, The Autoconf Manual}) and use @code{$(LN_S)} in
@file{Makefile.am}.
Note that if your package relies on a feature or a bug fix introduced in
a release, you can pass this version as an option to Automake to ensure
older releases will not be used. For instance, use this in your
-@file{configure.in}:
+@file{configure.ac}:
@example
AM_INIT_AUTOMAKE(1.6.1) dnl Require Automake 1.6.1 or better.
Automake outputs rules in @file{Makefile}s to rebuild these files. For
instance @command{make} will run @command{autoconf} to rebuild
-@file{configure} whenever @file{configure.in} is changed. This makes
+@file{configure} whenever @file{configure.ac} is changed. This makes
development safer by ensuring a @file{configure} is never out-of-date
-with respect to @file{configure.in}.
+with respect to @file{configure.ac}.
As generated files shipped in packages are up-to-date, and because
@command{tar} preserves times-tamps, these rebuild rules are not
This times tamp shift is troublesome when both sources and generated
files are kept under CVS. Because CVS processes files in alphabetical
-order, @file{configure.in} will appear older than @file{configure}
+order, @file{configure.ac} will appear older than @file{configure}
after a @command{cvs update} that updates both files, even if
-@file{configure} was newer than @file{configure.in} when it was
+@file{configure} was newer than @file{configure.ac} when it was
checked in. Calling @code{make} will then trigger a spurious rebuild
of @file{configure}.
Or people use a script to fix the timestamp after a checkout (the GCC
folks have such a script).
@item
-Or @file{configure.in} uses @code{AM_MAINTAINER_MODE}, which will
+Or @file{configure.ac} uses @code{AM_MAINTAINER_MODE}, which will
disable all these rebuild rules by default. This is further discussed
in @ref{maintainer-mode}.
@end itemize
projects / thirdparty / automake.git / commitdiff
