The maintainer's variant of @code{OBJCFLAGS}.
@item OBJCCOMPILE
-The command used to actually compile a Objective C source file. The
+The command used to actually compile an Objective C source file. The
file name is appended to form the complete command line.
@item OBJCLINK
-The command used to actually link a Objective C program.
+The command used to actually link an Objective C program.
@end vtable
variable @code{UPC} in @file{configure.ac}; the simplest way to do
this is to use the @code{AM_PROG_UPC} macro (@pxref{Public macros}).
-A few additional variables are defined when an Unified Parallel C
+A few additional variables are defined when a Unified Parallel C
source file is seen:
@vtable @code
The targets Automake generates are likewise given the @samp{$(EXEEXT)}
extension.
-The variables @code{TESTS}, @code{XFAIL_TESTS} (@pxref{Tests}) are also
-rewritten if it contains filenames that have been declared as programs
+The variables @code{TESTS} and @code{XFAIL_TESTS} (@pxref{Tests}) are also
+rewritten if they contain filenames that have been declared as programs
in the same @file{Makefile}. (This is mostly useful when some programs
from @code{check_PROGRAMS} are listed in @code{TESTS}.)
Scripts can be installed in @code{bindir}, @code{sbindir},
@code{libexecdir}, or @code{pkgdatadir}.
-Scripts that need not being installed can be listed in
+Scripts that need not be installed can be listed in
@code{noinst_SCRIPTS}, and among them, those which are needed only by
@samp{make check} should go in @code{check_SCRIPTS}.
@end example
@noindent
-to build @file{src/my_script} from @file{src/my_script.in}, then an
+to build @file{src/my_script} from @file{src/my_script.in}, then a
@file{src/Makefile.am} to install this script in @code{$(bindir)} can
be as simple as
echo '#define bindir "$(bindir)"' >$@@
@end example
-See how @file{bindir.h} get built first:
+See how @file{bindir.h} gets built first:
@example
% make
Autoconf Manual}).
At this point it should be clear that building @file{bindir.h} from
-@file{configure} work well for this example. @file{bindir.h} will exist
+@file{configure} works well for this example. @file{bindir.h} will exist
before you build any target, hence will not cause any dependency issue.
The Makefile can be shrunk as follows. We do not even have to mention
However, it's not always possible to build sources from
@file{configure}, especially when these sources are generated by a tool
-that needs to be built first...
+that needs to be built first.
@unnumberedsubsec Build @file{bindir.c}, not @file{bindir.h}.
@code{ELCFILES} is an internal Automake variable that normally lists
all @file{.elc} files that must be byte-compiled. Automake defines
@code{ELCFILES} automatically from @code{lisp_LISP}. Emptying this
-variable explicitly prevents byte-compilation to occur.
+variable explicitly prevents byte-compilation.
Since Automake 1.8, we now recommend using @code{lisp_DATA} instead. As
in
(@pxref{Top, , Introduction, gettext, GNU gettext utilities}).
The @code{gettext} support in Automake requires the addition of one or
-two subdirectories to the package, @file{po} and possibly also @file{intl}.
+two subdirectories to the package: @file{po} and possibly also @file{intl}.
The latter is needed if @code{AM_GNU_GETTEXT} is not invoked with the
@samp{external} argument, or if @code{AM_GNU_GETTEXT_INTL_SUBDIR} is used.
Automake ensures that these directories exist and are mentioned in
below). If you have called @code{AM_PATH_PYTHON} from
@file{configure.ac}, then you may use the variables
@code{python_PYTHON} or @code{pkgpython_PYTHON} to list Python source
-files in your @file{Makefile.am}, depending where you want your files
+files in your @file{Makefile.am}, depending on where you want your files
installed (see the definitions of @code{pythondir} and
@code{pkgpythondir} below).
install}, so running @code{make install-info} is pointless. This can
be prevented via the @code{no-installinfo} option. In this case,
@file{.info} files are not installed by default, and user must
-request this explicitly using @samp{make install-info}
+request this explicitly using @samp{make install-info}.
The following variables are used by the Texinfo build rules.
@file{.pdf} file. This defaults to @samp{$(TEXI2DVI) --pdf --batch}.
@item DVIPS
-The name of the command that build a @file{.ps} file out of a
+The name of the command that builds a @file{.ps} file out of a
@file{.dvi} file. This defaults to @samp{dvips}.
@item TEXINFO_TEX
nobase_include_HEADERS = stdio.h sys/types.h
@end example
-Will install @file{stdio.h} in @samp{$(includedir)} and @file{types.h}
+@noindent
+will install @file{stdio.h} in @samp{$(includedir)} and @file{types.h}
in @samp{$(includedir)/sys}.
For most file types, Automake will install multiple files at once, while
@trindex dist
The @code{dist} rule in the generated @file{Makefile.in} can be used
to generate a gzipped @code{tar} file and other flavors of archive for
-distribution. The files is named based on the @code{PACKAGE} and
+distribution. The file is named based on the @code{PACKAGE} and
@code{VERSION} variables defined by @code{AM_INIT_AUTOMAKE}
(@pxref{Macros}); more precisely the gzipped @code{tar} file is named
@samp{@var{package}-@var{version}.tar.gz}.
By default, the checking is done by the @code{distuninstallcheck} rule,
and the list of files in the install tree is generated by
-@samp{$(distuninstallcheck_listfiles}) (this is a variable whose value is
+@samp{$(distuninstallcheck_listfiles)} (this is a variable whose value is
a shell command to run that prints the list of files to stdout).
Either of these can be overridden to modify the behavior of
@item @option{no-define}
@cindex Option, @option{no-define}
@opindex no-define
-This options is meaningful only when passed as an argument to
+This option is meaningful only when passed as an argument to
@code{AM_INIT_AUTOMAKE}. It will prevent the @code{PACKAGE} and
-@code{VERSION} variables to be @code{AC_DEFINE}d.
+@code{VERSION} variables from being @code{AC_DEFINE}d.
@item @option{no-dependencies}
@cindex Option, @option{no-dependencies}
is then compressed according to the set of @option{no-dist-gzip},
@option{dist-bzip2}, @option{dist-lzma} and @option{dist-tarZ} options in use.)
-These options must be passed as argument to @code{AM_INIT_AUTOMAKE}
+These options must be passed as arguments to @code{AM_INIT_AUTOMAKE}
(@pxref{Macros}) because they can require additional configure checks.
Automake will complain if it sees such options in an
@code{AUTOMAKE_OPTIONS} variable.
directory-by-directory basis.
@trindex id
-Finally, Automake also emit rules to support the
+Finally, Automake also emits rules to support the
@uref{http://www.gnu.org/software/global/, GNU Global Tags program}.
The @code{GTAGS} rule runs Global Tags and puts the
result in the top build directory. The variable @code{GTAGS_ARGS}
type that Automake does not know about.
For instance, suppose you had a compiler that could compile @file{.foo}
-files to @file{.o} files. You would simply define an suffix rule for
+files to @file{.o} files. You would simply define a suffix rule for
your language:
@example
@end example
This was the simpler and more common case. In other cases, you will
-have to help Automake to figure which extensions you are defining your
-suffix rule for. This usually happens when your extensions does not
+have to help Automake to figure out which extensions you are defining your
+suffix rule for. This usually happens when your extension does not
start with a dot. Then, all you have to do is to put a list of new
suffixes in the @code{SUFFIXES} variable @strong{before} you define your
implicit rule.
-For instance, the following definition prevents Automake to misinterpret
-@samp{.idlC.cpp:} as an attempt to transform @file{.idlC} files into
+For instance, the following definition prevents Automake from misinterpreting
+the @samp{.idlC.cpp:} rule as an attempt to transform @file{.idlC} files into
@file{.cpp} files.
@example
@cindex copying semantics
-These copying semantics means that many problems can be worked around
+These copying semantics mean that many problems can be worked around
by simply adding some @command{make} variables and rules to
@file{Makefile.am}. Automake will ignore these additions.
@command{automake} itself), it is possible to have conflicting
definitions of rules or variables. When building @file{Makefile.in}
the following priorities are respected by @command{automake} to ensure
-the user always have the last word. User defined variables in
+the user always has the last word. User defined variables in
@file{Makefile.am} have priority over variables @code{AC_SUBST}ed from
@file{configure.ac}, and @code{AC_SUBST}ed variables have priority
-over @command{automake}-defined variables. As far rules are
+over @command{automake}-defined variables. As far as rules are
concerned, a user-defined rule overrides any
@command{automake}-defined rule for the same target.
settings of Automake, or replace some of its rules. Overriding
Automake rules is often inadvisable, particularly in the topmost
directory of a package with subdirectories. The @option{-Woverride}
-option (@pxref{Invoking Automake}) comes handy to catch overridden
+option (@pxref{Invoking Automake}) comes in handy to catch overridden
definitions.
-Note that Automake does not make any difference between rules with
+Note that Automake does not make any distinction between rules with
commands and rules that only specify dependencies. So it is not
possible to append new dependencies to an @command{automake}-defined
target without redefining the entire rule.
processes a @file{Makefile} (@pxref{Preset Output Variables, , Preset
Output Variables, autoconf, The Autoconf Manual}), they are not
computed by the Makefile like the aforementioned @samp{$(distdir)} and
-@samp{$(top_distdir)} variables..
+@samp{$(top_distdir)} variables.
It is sometimes inconvenient to modify a third-party @file{Makefile}
to introduce the above required targets. For instance, one may want to
@cindex @file{GNUmakefile} including @file{Makefile}
Here are two other ideas. If GNU make is assumed, one possibility is
to add to that subdirectory a @file{GNUmakefile} that defines the
-required targets and include the third-party @file{Makefile}. For
+required targets and includes the third-party @file{Makefile}. For
this to work in VPATH builds, @file{GNUmakefile} must lie in the build
directory; the easiest way to do this is to write a
@file{GNUmakefile.in} instead, and have it processed with
Pushing this idea to the extreme, it is also possible to ignore the
subproject build system and build everything from this proxy
-@file{Makefile.am}. This might sounds very sensible if you need VPATH
+@file{Makefile.am}. This might sound very sensible if you need VPATH
builds but the subproject does not support them.
@node Distributing
Things get worse when maintaining a large tree of packages, each one
requiring a different version of Automake. In the past, this meant that
-any developer (and sometime users) had to install several versions of
+any developer (and sometimes users) had to install several versions of
Automake in different places, and switch @samp{$PATH} appropriately for
each package.
out-of-date file is up-to-date.
For instance, suppose a developer has modified @file{Makefile.am} and
-has rebuilt @file{Makefile.in}. He then decide to do a last-minute
+has rebuilt @file{Makefile.in}. He then decides to do a last-minute
change to @file{Makefile.am} right before checking in both files
(without rebuilding @file{Makefile.in} to account for the change).
-This last change to @file{Makefile.am} make the copy of
+This last change to @file{Makefile.am} makes the copy of
@file{Makefile.in} out-of-date. Since CVS processes files
-alphabetically, when another developer @samp{cvs update} his or her
+alphabetically, when another developer @samp{cvs update}s his or her
tree, @file{Makefile.in} will happen to be newer than
-@file{Makefile.am}. This other developer will not see
+@file{Makefile.am}. This other developer will not see that
@file{Makefile.in} is out-of-date.
@end itemize
attempt to fix timestamps in a way that allows the build to continue.
For instance, @command{missing} will touch @file{configure} if
@command{autoconf} is not installed. When all distributed files are
-kept under CVS, this feature of @command{missing} allows user
+kept under CVS, this feature of @command{missing} allows a user
@emph{with no maintainer tools} to build a package off CVS, bypassing
any timestamp inconsistency implied by @samp{cvs update}.
@cindex @code{AM_MAINTAINER_MODE}, purpose
@acindex AM_MAINTAINER_MODE
-@code{AM_MAINTAINER_MODE} allows to choose whether the so called
+@code{AM_MAINTAINER_MODE} allows you to choose whether the so called
"rebuild rules" should be enabled or disabled. With
@code{AM_MAINTAINER_MODE([enable])}, they are enabled by default,
otherwise they are disabled by default. In the latter case, if
you have @code{AM_MAINTAINER_MODE} in @file{configure.ac}, and run
@samp{./configure && make}, then @command{make} will *never* attempt to
-rebuilt @file{configure}, @file{Makefile.in}s, Lex or Yacc outputs, etc.
+rebuild @file{configure}, @file{Makefile.in}s, Lex or Yacc outputs, etc.
I.e., this disables build rules for files that are usually distributed
and that users should normally not have to update.
Several years ago Fran@,{c}ois Pinard pointed out several arguments
against this @code{AM_MAINTAINER_MODE} macro. Most of them relate to
insecurity. By removing dependencies you get non-dependable builds:
-change to sources files can have no effect on generated files and this
+changes to sources files can have no effect on generated files and this
can be very confusing when unnoticed. He adds that security shouldn't
be reserved to maintainers (what @option{--enable-maintainer-mode}
suggests), on the contrary. If one user has to modify a
Even if you don't care about portability, and are tempted to use
@samp{$(wildcard ...)} anyway because you target only GNU Make, you
-should know there are many places where Automake need to know exactly
+should know there are many places where Automake needs to know exactly
which files should be processed. As Automake doesn't know how to
expand @samp{$(wildcard ...)}, you cannot use it in these places.
@samp{$(wildcard ...)} is a black box comparable to @code{AC_SUBST}ed
14-byte limit, but nowadays it's normally safe to assume the
more-generous @acronym{XOPEN} limit of 255 bytes. @acronym{POSIX}
limits file names to 255 bytes (@acronym{XOPEN} allows 1023 bytes),
-but you may want to limit a source tarball to file names to 99 bytes
+but you may want to limit a source tarball to file names of 99 bytes
to avoid interoperability problems with old versions of @command{tar}.
If you depart from these rules (e.g., by using non-@acronym{ASCII}
which we want to build a man page using @command{help2man}. GNU
@command{help2man} produces simple manual pages from the @option{--help}
and @option{--version} output of other commands (@pxref{Top, , Overview,
-help2man, The Help2man Manual}). Because we don't to force want our
+help2man, The Help2man Manual}). Because we don't want to force our
users to install @command{help2man}, we decide to distribute the
generated man page using the following setup.
will always appear to be newer than the distributed @file{foo.1}.
@samp{make distcheck} caught an inconsistency in our package. Our
-intent was to distribute @file{foo.1} so users do not need installing
-@command{help2man}, however since this our rule causes this file to be
+intent was to distribute @file{foo.1} so users do not need to install
+@command{help2man}, however since this rule causes this file to be
always rebuilt, users @emph{do} need @command{help2man}. Either we
should ensure that @file{foo.1} is not rebuilt by users, or there is
no point in distributing @file{foo.1}.
@end example
@noindent
-is all what is needed here if no per-target flags are used.
+is all that is needed here if no per-target flags are used.
You should not add options to these user variables within
@file{configure} either, for the same reason. Occasionally you need
(@pxref{Tags}) use @code{ETAGSFLAGS}, @code{AM_ETAGSFLAGS},
@code{CTAGSFLAGS}, and @code{AM_CTAGSFLAGS}. Java rules
(@pxref{Java}) use @code{JAVACFLAGS} and @code{AM_JAVACFLAGS}. None
-of these rules supports per-target flags (yet).
+of these rules support per-target flags (yet).
To some extent, even @code{AM_MAKEFLAGS} (@pxref{Subdirectories})
obeys this naming scheme. The slight difference is that
However you should not think that all variables ending with
@code{FLAGS} follow this convention. For instance,
-@code{DISTCHECK_CONFIGURE_FLAGS} (@pxref{Dist}),
+@code{DISTCHECK_CONFIGURE_FLAGS} (@pxref{Dist}) and
@code{ACLOCAL_AMFLAGS} (see @ref{Rebuilding} and @ref{Local Macros}),
are two variables that are only useful to the maintainer and have no
user counterpart.
@command{automake} doesn't actually look whether source files are
shared to decide if it must rename objects. It will just rename all
objects of a target as soon as it sees per-target compilation flags
-are used.
+used.
It's OK to share object files when per-target compilation flags are not
used. For instance, @file{true} and @file{false} will both use
@noindent
by default @code{sysconfdir} will be @samp{$(prefix)/etc}, because
this is what the GNU Standards require. When such a package is
-installed on a FHS compliant system, the installer will have to set
+installed on an FHS compliant system, the installer will have to set
@samp{--sysconfdir=/etc}. As the maintainer of the package you
should not be concerned by such site policies: use the appropriate
-standard directory variable to install your files so that installer
+standard directory variable to install your files so that the installer
can easily redefine these variables to match their site conventions.
Installing files that should be used by another package is slightly
more involved. Let's take an example and assume you want to install
-shared library that is a Python extension module. If you ask Python
+a shared library that is a Python extension module. If you ask Python
where to install the library, it will answer something like this:
@example
Of course not all tools are as advanced as Python regarding that
substitution of @var{prefix}. So another strategy is to figure the
-part of the of the installation directory that must be preserved. For
+part of the installation directory that must be preserved. For
instance, here is how @code{AM_PATH_LISPDIR} (@pxref{Emacs Lisp})
computes @samp{$(lispdir)}:
@samp{$@{datadir@}} appropriately.
The emacs case looks complicated because it processes a list and
-expect two possible layouts, otherwise it's easy, and the benefit for
+expects two possible layouts, otherwise it's easy, and the benefits for
non-root users are really worth the extra @command{sed} invocation.
(@code{AM_PROGRAMS} has since then been renamed to
@code{EXTRA_PROGRAMS}.)
-Similarly scripts, static libraries, and data can built and installed
+Similarly scripts, static libraries, and data can be built and installed
using the @code{LIBRARIES}, @code{SCRIPTS}, and @code{DATA} variables.
However @code{LIBRARIES} were treated a bit specially in that Automake
did automatically supply the @file{lib} and @file{.a} prefixes.
@item 1995-11-26 Automake 0.21
-In less time that it takes to cook a frozen pizza, Tom rewrites
+In less time than it takes to cook a frozen pizza, Tom rewrites
Automake using Perl. At this time Perl 5 is only one year old, and
Perl 4.036 is in use at many sites. Supporting several Perl versions
has been a source of problems through the whole history of Automake.
All the third-party Autoconf macros, written mostly by Fran@,cois
Pinard (and later Jim Meyering), are distributed in Automake's
hand-written @file{aclocal.m4} file. Package maintainers are expected
-to extract the necessary macros from this file. (In previous version
+to extract the necessary macros from this file. (In previous versions
you had to copy and paste them from the manual...)
@item 1996-03-11 Automake 0.31