This is automake.info, produced by makeinfo version 4.8 from automake.texi. This manual is for GNU Automake (version 1.10, 15 October 2006), a program that creates GNU standards-compliant Makefiles from template files. Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being "A GNU Manual," and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled "GNU Free Documentation License." (a) The FSF's Back-Cover Text is: "You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development." INFO-DIR-SECTION Software development START-INFO-DIR-ENTRY * Automake: (automake). Making GNU standards-compliant Makefiles. END-INFO-DIR-ENTRY INFO-DIR-SECTION Individual utilities START-INFO-DIR-ENTRY * aclocal: (automake)Invoking aclocal. Generating aclocal.m4. * automake: (automake)Invoking Automake. Generating Makefile.in. END-INFO-DIR-ENTRY  File: automake.info, Node: Suffixes, Next: Multilibs, Prev: Tags, Up: Miscellaneous 18.2 Handling new file extensions ================================= It is sometimes useful to introduce a new implicit rule to handle a file type that Automake does not know about. For instance, suppose you had a compiler that could compile `.foo' files to `.o' files. You would simply define an suffix rule for your language: .foo.o: foocc -c -o $@ $< Then you could directly use a `.foo' file in a `_SOURCES' variable and expect the correct results: bin_PROGRAMS = doit doit_SOURCES = doit.foo 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 start with a dot. Then, all you have to do is to put a list of new suffixes in the `SUFFIXES' variable *before* you define your implicit rule. For instance, the following definition prevents Automake to misinterpret `.idlC.cpp:' as an attempt to transform `.idlC' files into `.cpp' files. SUFFIXES = .idl C.cpp .idlC.cpp: # whatever As you may have noted, the `SUFFIXES' variable behaves like the `.SUFFIXES' special target of `make'. You should not touch `.SUFFIXES' yourself, but use `SUFFIXES' instead and let Automake generate the suffix list for `.SUFFIXES'. Any given `SUFFIXES' go at the start of the generated suffixes list, followed by Automake generated suffixes not already in the list.  File: automake.info, Node: Multilibs, Prev: Suffixes, Up: Miscellaneous 18.3 Support for Multilibs ========================== Automake has support for an obscure feature called multilibs. A "multilib" is a library that is built for multiple different ABIs at a single time; each time the library is built with a different target flag combination. This is only useful when the library is intended to be cross-compiled, and it is almost exclusively used for compiler support libraries. The multilib support is still experimental. Only use it if you are familiar with multilibs and can debug problems you might encounter.  File: automake.info, Node: Include, Next: Conditionals, Prev: Miscellaneous, Up: Top 19 Include ********** Automake supports an `include' directive that can be used to include other `Makefile' fragments when `automake' is run. Note that these fragments are read and interpreted by `automake', not by `make'. As with conditionals, `make' has no idea that `include' is in use. There are two forms of `include': `include $(srcdir)/file' Include a fragment that is found relative to the current source directory. `include $(top_srcdir)/file' Include a fragment that is found relative to the top source directory. Note that if a fragment is included inside a conditional, then the condition applies to the entire contents of that fragment. Makefile fragments included this way are always distributed because they are needed to rebuild `Makefile.in'.  File: automake.info, Node: Conditionals, Next: Gnits, Prev: Include, Up: Top 20 Conditionals *************** Automake supports a simple type of conditionals. Usage ===== Before using a conditional, you must define it by using `AM_CONDITIONAL' in the `configure.ac' file (*note Macros::). -- Macro: AM_CONDITIONAL (CONDITIONAL, CONDITION) The conditional name, CONDITIONAL, should be a simple string starting with a letter and containing only letters, digits, and underscores. It must be different from `TRUE' and `FALSE' that are reserved by Automake. The shell CONDITION (suitable for use in a shell `if' statement) is evaluated when `configure' is run. Note that you must arrange for _every_ `AM_CONDITIONAL' to be invoked every time `configure' is run. If `AM_CONDITIONAL' is run conditionally (e.g., in a shell `if' statement), then the result will confuse automake. Conditionals typically depend upon options that the user provides to the `configure' script. Here is an example of how to write a conditional that is true if the user uses the `--enable-debug' option. AC_ARG_ENABLE([debug], [ --enable-debug Turn on debugging], [case "${enableval}" in yes) debug=true ;; no) debug=false ;; *) AC_MSG_ERROR([bad value ${enableval} for --enable-debug]) ;; esac],[debug=false]) AM_CONDITIONAL([DEBUG], [test x$debug = xtrue]) Here is an example of how to use that conditional in `Makefile.am': if DEBUG DBG = debug else DBG = endif noinst_PROGRAMS = $(DBG) This trivial example could also be handled using `EXTRA_PROGRAMS' (*note Conditional Programs::). You may only test a single variable in an `if' statement, possibly negated using `!'. The `else' statement may be omitted. Conditionals may be nested to any depth. You may specify an argument to `else' in which case it must be the negation of the condition used for the current `if'. Similarly you may specify the condition that is closed by an `end': if DEBUG DBG = debug else !DEBUG DBG = endif !DEBUG Unbalanced conditions are errors. The `else' branch of the above two examples could be omitted, since assigning the empty string to an otherwise undefined variable makes no difference. Portability =========== Note that conditionals in Automake are not the same as conditionals in GNU Make. Automake conditionals are checked at configure time by the `configure' script, and affect the translation from `Makefile.in' to `Makefile'. They are based on options passed to `configure' and on results that `configure' has discovered about the host system. GNU Make conditionals are checked at `make' time, and are based on variables passed to the make program or defined in the `Makefile'. Automake conditionals will work with any make program. Limits ====== Conditionals should enclose complete statements like variables or rules definitions. Automake cannot deal with conditionals used inside a variable definition, for instance, and is not even able to diagnose this situation. The following example would not work: # This syntax is not understood by Automake AM_CPPFLAGS = \ -DFEATURE_A \ if WANT_DEBUG -DDEBUG \ endif -DFEATURE_B However the intended definition of `AM_CPPFLAGS' can be achieved with if WANT_DEBUG DEBUGFLAGS = -DDEBUG endif AM_CPPFLAGS = -DFEATURE_A $(DEBUGFLAGS) -DFEATURE_B or AM_CPPFLAGS = -DFEATURE_A if WANT_DEBUG AM_CPPFLAGS += -DDEBUG endif AM_CPPFLAGS += -DFEATURE_B  File: automake.info, Node: Gnits, Next: Cygnus, Prev: Conditionals, Up: Top 21 The effect of `--gnu' and `--gnits' ************************************** The `--gnu' option (or `gnu' in the `AUTOMAKE_OPTIONS' variable) causes `automake' to check the following: * The files `INSTALL', `NEWS', `README', `AUTHORS', and `ChangeLog', plus one of `COPYING.LIB', `COPYING.LESSER' or `COPYING', are required at the topmost directory of the package. * The options `no-installman' and `no-installinfo' are prohibited. Note that this option will be extended in the future to do even more checking; it is advisable to be familiar with the precise requirements of the GNU standards. Also, `--gnu' can require certain non-standard GNU programs to exist for use by various maintainer-only rules; for instance, in the future `pathchk' might be required for `make dist'. The `--gnits' option does everything that `--gnu' does, and checks the following as well: * `make installcheck' will check to make sure that the `--help' and `--version' really print a usage message and a version string, respectively. This is the `std-options' option (*note Options::). * `make dist' will check to make sure the `NEWS' file has been updated to the current version. * `VERSION' is checked to make sure its format complies with Gnits standards. * If `VERSION' indicates that this is an alpha release, and the file `README-alpha' appears in the topmost directory of a package, then it is included in the distribution. This is done in `--gnits' mode, and no other, because this mode is the only one where version number formats are constrained, and hence the only mode where Automake can automatically determine whether `README-alpha' should be included. * The file `THANKS' is required.  File: automake.info, Node: Cygnus, Next: Not Enough, Prev: Gnits, Up: Top 22 The effect of `--cygnus' *************************** Some packages, notably GNU GCC and GNU gdb, have a build environment originally written at Cygnus Support (subsequently renamed Cygnus Solutions, and then later purchased by Red Hat). Packages with this ancestry are sometimes referred to as "Cygnus" trees. A Cygnus tree has slightly different rules for how a `Makefile.in' is to be constructed. Passing `--cygnus' to `automake' will cause any generated `Makefile.in' to comply with Cygnus rules. Here are the precise effects of `--cygnus': * Info files are always created in the build directory, and not in the source directory. * `texinfo.tex' is not required if a Texinfo source file is specified. The assumption is that the file will be supplied, but in a place that Automake cannot find. This assumption is an artifact of how Cygnus packages are typically bundled. * `make dist' is not supported, and the rules for it are not generated. Cygnus-style trees use their own distribution mechanism. * Certain tools will be searched for in the build tree as well as in the user's `PATH'. These tools are `runtest', `expect', `makeinfo' and `texi2dvi'. * `--foreign' is implied. * The options `no-installinfo' and `no-dependencies' are implied. * The macros `AM_MAINTAINER_MODE' and `AM_CYGWIN32' are required. * The `check' target doesn't depend on `all'. GNU maintainers are advised to use `gnu' strictness in preference to the special Cygnus mode. Some day, perhaps, the differences between Cygnus trees and GNU trees will disappear (for instance, as GCC is made more standards compliant). At that time the special Cygnus mode will be removed.  File: automake.info, Node: Not Enough, Next: Distributing, Prev: Cygnus, Up: Top 23 When Automake Isn't Enough ***************************** In some situations, where Automake is not up to one task, one has to resort to handwritten rules or even handwritten `Makefile's. * Menu: * Extending:: Adding new rules or overriding existing ones. * Third-Party Makefiles:: Integrating Non-Automake `Makefile's.  File: automake.info, Node: Extending, Next: Third-Party Makefiles, Up: Not Enough 23.1 Extending Automake Rules ============================= With some minor exceptions (like `_PROGRAMS' variables being rewritten to append `$(EXEEXT)'), the contents of a `Makefile.am' is copied to `Makefile.in' verbatim. These copying semantics means that many problems can be worked around by simply adding some `make' variables and rules to `Makefile.am'. Automake will ignore these additions. Since a `Makefile.in' is built from data gathered from three different places (`Makefile.am', `configure.ac', and `automake' itself), it is possible to have conflicting definitions of rules or variables. When building `Makefile.in' the following priorities are respected by `automake' to ensure the user always have the last word. User defined variables in `Makefile.am' have priority over variables `AC_SUBST'ed from `configure.ac', and `AC_SUBST'ed variables have priority over `automake'-defined variables. As far rules are concerned, a user-defined rule overrides any `automake'-defined rule for the same target. These overriding semantics make it possible to fine tune some default 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 `-Woverride' option (*note Invoking Automake::) comes handy to catch overridden definitions. Note that Automake does not make any difference between rules with commands and rules that only specify dependencies. So it is not possible to append new dependencies to an `automake'-defined target without redefining the entire rule. However, various useful targets have a `-local' version you can specify in your `Makefile.am'. Automake will supplement the standard target with these user-supplied targets. The targets that support a local version are `all', `info', `dvi', `ps', `pdf', `html', `check', `install-data', `install-dvi', `install-exec', `install-html', `install-info', `install-pdf', `install-ps', `uninstall', `installdirs', `installcheck' and the various `clean' targets (`mostlyclean', `clean', `distclean', and `maintainer-clean'). Note that there are no `uninstall-exec-local' or `uninstall-data-local' targets; just use `uninstall-local'. It doesn't make sense to uninstall just data or just executables. For instance, here is one way to erase a subdirectory during `make clean' (*note Clean::). clean-local: -rm -rf testSubDir Older version of this manual used to show how to use `install-data-local' to install a file to some hard-coded location, but you should avoid this. (*note Hard-Coded Install Paths::) Some rule also have a way to run another rule, called a "hook", after their work is done. The hook is named after the principal target, with `-hook' appended. The targets allowing hooks are `install-data', `install-exec', `uninstall', `dist', and `distcheck'. For instance, here is how to create a hard link to an installed program: install-exec-hook: ln $(DESTDIR)$(bindir)/program$(EXEEXT) \ $(DESTDIR)$(bindir)/proglink$(EXEEXT) Although cheaper and more portable than symbolic links, hard links will not work everywhere (for instance, OS/2 does not have `ln'). Ideally you should fall back to `cp -p' when `ln' does not work. An easy way, if symbolic links are acceptable to you, is to add `AC_PROG_LN_S' to `configure.ac' (*note Particular Program Checks: (autoconf)Particular Programs.) and use `$(LN_S)' in `Makefile.am'. For instance, here is how you could install a versioned copy of a program using `$(LN_S)': install-exec-hook: cd $(DESTDIR)$(bindir) && \ mv -f prog$(EXEEXT) prog-$(VERSION)$(EXEEXT) && \ $(LN_S) prog-$(VERSION)$(EXEEXT) prog$(EXEEXT) Note that we rename the program so that a new version will erase the symbolic link, not the real binary. Also we `cd' into the destination directory in order to create relative links. When writing `install-exec-hook' or `install-data-hook', please bear in mind that the exec/data distinction is based on the installation directory, not on the primary used (*note Install::). So a `foo_SCRIPTS' will be installed by `install-data', and a `barexec_SCRIPTS' will be installed by `install-exec'. You should define your hooks consequently.  File: automake.info, Node: Third-Party Makefiles, Prev: Extending, Up: Not Enough 23.2 Third-Party `Makefile's ============================ In most projects all `Makefile's are generated by Automake. In some cases, however, projects need to embed subdirectories with handwritten `Makefile's. For instance, one subdirectory could be a third-party project with its own build system, not using Automake. It is possible to list arbitrary directories in `SUBDIRS' or `DIST_SUBDIRS' provided each of these directories has a `Makefile' that recognizes all the following recursive targets. When a user runs one of these targets, that target is run recursively in all subdirectories. This is why it is important that even third-party `Makefile's support them. `all' Compile the entire package. This is the default target in Automake-generated `Makefile's, but it does not need to be the default in third-party `Makefile's. `distdir' Copy files to distribute into `$(distdir)', before a tarball is constructed. Of course this target is not required if the `no-dist' option (*note Options::) is used. The variables `$(top_distdir)' and `$(distdir)' (*note Dist::) will be passed from the outer package to the subpackage when the `distdir' target is invoked. These two variables have been adjusted for the directory that is being recursed into, so they are ready to use. `install' `install-data' `install-exec' `uninstall' Install or uninstall files (*note Install::). `install-dvi' `install-html' `install-info' `install-ps' `install-pdf' Install only some specific documentation format (*note Texinfo::). `installdirs' Create install directories, but do not install any files. `check' `installcheck' Check the package (*note Tests::). `mostlyclean' `clean' `distclean' `maintainer-clean' Cleaning rules (*note Clean::). `dvi' `pdf' `ps' `info' `html' Build the documentation in various formats (*note Texinfo::). `tags' `ctags' Build `TAGS' and `CTAGS' (*note Tags::). If you have ever used Gettext in a project, this is a good example of how third-party `Makefile's can be used with Automake. The `Makefile's `gettextize' puts in the `po/' and `intl/' directories are handwritten `Makefile's that implement all these targets. That way they can be added to `SUBDIRS' in Automake packages. Directories that are only listed in `DIST_SUBDIRS' but not in `SUBDIRS' need only the `distclean', `maintainer-clean', and `distdir' rules (*note Conditional Subdirectories::). Usually, many of these rules are irrelevant to the third-party subproject, but they are required for the whole package to work. It's OK to have a rule that does nothing, so if you are integrating a third-party project with no documentation or tag support, you could simply augment its `Makefile' as follows: EMPTY_AUTOMAKE_TARGETS = dvi pdf ps info html tags ctags .PHONY: $(EMPTY_AUTOMAKE_TARGETS) $(EMPTY_AUTOMAKE_TARGETS): Another aspect of integrating third-party build systems is whether they support VPATH builds (*note VPATH Builds::). Obviously if the subpackage does not support VPATH builds the whole package will not support VPATH builds. This in turns means that `make distcheck' will not work, because it relies on VPATH builds. Some people can live without this (actually, many Automake users have never heard of `make distcheck'). Other people may prefer to revamp the existing `Makefile's to support VPATH. Doing so does not necessarily require Automake, only Autoconf is needed (*note Build Directories: (autoconf)Build Directories.). The necessary substitutions: `@srcdir@', `@top_srcdir@', and `@top_builddir@' are defined by `configure' when it processes a `Makefile' (*note Preset Output Variables: (autoconf)Preset Output Variables.), they are not computed by the Makefile like the aforementioned `$(distdir)' and `$(top_distdir)' variables.. It is sometimes inconvenient to modify a third-party `Makefile' to introduce the above required targets. For instance, one may want to keep the third-party sources untouched to ease upgrades to new versions. Here are two other ideas. If GNU make is assumed, one possibility is to add to that subdirectory a `GNUmakefile' that defines the required targets and include the third-party `Makefile'. For this to work in VPATH builds, `GNUmakefile' must lie in the build directory; the easiest way to do this is to write a `GNUmakefile.in' instead, and have it processed with `AC_CONFIG_FILES' from the outer package. For example if we assume `Makefile' defines all targets except the documentation targets, and that the `check' target is actually called `test', we could write `GNUmakefile' (or `GNUmakefile.in') like this: # First, include the real Makefile include Makefile # Then, define the other targets needed by Automake Makefiles. .PHONY: dvi pdf ps info html check dvi pdf ps info html: check: test A similar idea that does not use `include' is to write a proxy `Makefile' that dispatches rules to the real `Makefile', either with `$(MAKE) -f Makefile.real $(AM_MAKEFLAGS) target' (if it's OK to rename the original `Makefile') or with `cd subdir && $(MAKE) $(AM_MAKEFLAGS) target' (if it's OK to store the subdirectory project one directory deeper). The good news is that this proxy `Makefile' can be generated with Automake. All we need are `-local' targets (*note Extending::) that perform the dispatch. Of course the other Automake features are available, so you could decide to let Automake perform distribution or installation. Here is a possible `Makefile.am': all-local: cd subdir && $(MAKE) $(AM_MAKEFLAGS) all check-local: cd subdir && $(MAKE) $(AM_MAKEFLAGS) test clean-local: cd subdir && $(MAKE) $(AM_MAKEFLAGS) clean # Assuming the package knows how to install itself install-data-local: cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-data install-exec-local: cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-exec uninstall-local: cd subdir && $(MAKE) $(AM_MAKEFLAGS) uninstall # Distribute files from here. EXTRA_DIST = subdir/Makefile subdir/program.c ... Pushing this idea to the extreme, it is also possible to ignore the subproject build system and build everything from this proxy `Makefile.am'. This might sounds very sensible if you need VPATH builds but the subproject does not support them.  File: automake.info, Node: Distributing, Next: API versioning, Prev: Not Enough, Up: Top 24 Distributing `Makefile.in's ****************************** Automake places no restrictions on the distribution of the resulting `Makefile.in's. We still encourage software authors to distribute their work under terms like those of the GPL, but doing so is not required to use Automake. Some of the files that can be automatically installed via the `--add-missing' switch do fall under the GPL. However, these also have a special exception allowing you to distribute them with your package, regardless of the licensing you choose.  File: automake.info, Node: API versioning, Next: Upgrading, Prev: Distributing, Up: Top 25 Automake API versioning ************************** New Automake releases usually include bug fixes and new features. Unfortunately they may also introduce new bugs and incompatibilities. This makes four reasons why a package may require a particular Automake version. 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 Automake in different places, and switch `$PATH' appropriately for each package. Starting with version 1.6, Automake installs versioned binaries. This means you can install several versions of Automake in the same `$prefix', and can select an arbitrary Automake version by running `automake-1.6' or `automake-1.7' without juggling with `$PATH'. Furthermore, `Makefile''s generated by Automake 1.6 will use `automake-1.6' explicitly in their rebuild rules. The number `1.6' in `automake-1.6' is Automake's API version, not Automake's version. If a bug fix release is made, for instance Automake 1.6.1, the API version will remain 1.6. This means that a package that works with Automake 1.6 should also work with 1.6.1; after all, this is what people expect from bug fix releases. 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 `configure.ac': AM_INIT_AUTOMAKE([1.6.1]) dnl Require Automake 1.6.1 or better. or, in a particular `Makefile.am': AUTOMAKE_OPTIONS = 1.6.1 # Require Automake 1.6.1 or better. Automake will print an error message if its version is older than the requested version. What is in the API ================== Automake's programming interface is not easy to define. Basically it should include at least all *documented* variables and targets that a `Makefile.am' author can use, any behavior associated with them (e.g., the places where `-hook''s are run), the command line interface of `automake' and `aclocal', ... What is not in the API ====================== Every undocumented variable, target, or command line option, is not part of the API. You should avoid using them, as they could change from one version to the other (even in bug fix releases, if this helps to fix a bug). If it turns out you need to use such a undocumented feature, contact and try to get it documented and exercised by the test-suite.  File: automake.info, Node: Upgrading, Next: FAQ, Prev: API versioning, Up: Top 26 Upgrading a Package to a Newer Automake Version ************************************************** Automake maintains three kind of files in a package. * `aclocal.m4' * `Makefile.in's * auxiliary tools like `install-sh' or `py-compile' `aclocal.m4' is generated by `aclocal' and contains some Automake-supplied M4 macros. Auxiliary tools are installed by `automake --add-missing' when needed. `Makefile.in's are built from `Makefile.am' by `automake', and rely on the definitions of the M4 macros put in `aclocal.m4' as well as the behavior of the auxiliary tools installed. Because all these files are closely related, it is important to regenerate all of them when upgrading to a newer Automake release. The usual way to do that is aclocal # with any option needed (such a -I m4) autoconf automake --add-missing --force-missing or more conveniently: autoreconf -vfi The use of `--force-missing' ensures that auxiliary tools will be overridden by new versions (*note Invoking Automake::). It is important to regenerate all these files each time Automake is upgraded, even between bug fixes releases. For instance, it is not unusual for a bug fix to involve changes to both the rules generated in `Makefile.in' and the supporting M4 macros copied to `aclocal.m4'. Presently `automake' is able to diagnose situations where `aclocal.m4' has been generated with another version of `aclocal'. However it never checks whether auxiliary scripts are up-to-date. In other words, `automake' will tell you when `aclocal' needs to be rerun, but it will never diagnose a missing `--force-missing'. Before upgrading to a new major release, it is a good idea to read the file `NEWS'. This file lists all changes between releases: new features, obsolete constructs, known incompatibilities, and workarounds.  File: automake.info, Node: FAQ, Next: History, Prev: Upgrading, Up: Top 27 Frequently Asked Questions about Automake ******************************************** This chapter covers some questions that often come up on the mailing lists. * Menu: * CVS:: CVS and generated files * maintainer-mode:: missing and AM_MAINTAINER_MODE * wildcards:: Why doesn't Automake support wildcards? * limitations on file names:: Limitations on source and installed file names * distcleancheck:: Files left in build directory after distclean * Flag Variables Ordering:: CFLAGS vs. AM_CFLAGS vs. mumble_CFLAGS * renamed objects:: Why are object files sometimes renamed? * Per-Object Flags:: How to simulate per-object flags? * Multiple Outputs:: Writing rules for tools with many output files * Hard-Coded Install Paths:: Installing to Hard-Coded Locations  File: automake.info, Node: CVS, Next: maintainer-mode, Up: FAQ 27.1 CVS and generated files ============================ 27.1.1 Background: distributed generated files ---------------------------------------------- Packages made with Autoconf and Automake ship with some generated files like `configure' or `Makefile.in'. These files were generated on the developer's host and are distributed so that end-users do not have to install the maintainer tools required to rebuild them. Other generated files like Lex scanners, Yacc parsers, or Info documentation, are usually distributed on similar grounds. Automake outputs rules in `Makefile's to rebuild these files. For instance, `make' will run `autoconf' to rebuild `configure' whenever `configure.ac' is changed. This makes development safer by ensuring a `configure' is never out-of-date with respect to `configure.ac'. As generated files shipped in packages are up-to-date, and because `tar' preserves times-tamps, these rebuild rules are not triggered when a user unpacks and builds a package. 27.1.2 Background: CVS and timestamps ------------------------------------- Unless you use CVS keywords (in which case files must be updated at commit time), CVS preserves timestamp during `cvs commit' and `cvs import -d' operations. When you check out a file using `cvs checkout' its timestamp is set to that of the revision that is being checked out. However, during `cvs update', files will have the date of the update, not the original timestamp of this revision. This is meant to make sure that `make' notices sources files have been updated. This timestamp shift is troublesome when both sources and generated files are kept under CVS. Because CVS processes files in alphabetical order, `configure.ac' will appear older than `configure' after a `cvs update' that updates both files, even if `configure' was newer than `configure.ac' when it was checked in. Calling `make' will then trigger a spurious rebuild of `configure'. 27.1.3 Living with CVS in Autoconfiscated projects -------------------------------------------------- There are basically two clans amongst maintainers: those who keep all distributed files under CVS, including generated files, and those who keep generated files _out_ of CVS. All files in CVS ................ * The CVS repository contains all distributed files so you know exactly what is distributed, and you can checkout any prior version entirely. * Maintainers can see how generated files evolve (for instance, you can see what happens to your `Makefile.in's when you upgrade Automake and make sure they look OK). * Users do not need the autotools to build a checkout of the project, it works just like a released tarball. * If users use `cvs update' to update their copy, instead of `cvs checkout' to fetch a fresh one, timestamps will be inaccurate. Some rebuild rules will be triggered and attempt to run developer tools such as `autoconf' or `automake'. Actually, calls to such tools are all wrapped into a call to the `missing' script discussed later (*note maintainer-mode::). `missing' will take care of fixing the timestamps when these tools are not installed, so that the build can continue. * In distributed development, developers are likely to have different version of the maintainer tools installed. In this case rebuilds triggered by timestamp lossage will lead to spurious changes to generated files. There are several solutions to this: * All developers should use the same versions, so that the rebuilt files are identical to files in CVS. (This starts to be difficult when each project you work on uses different versions.) * Or people use a script to fix the timestamp after a checkout (the GCC folks have such a script). * Or `configure.ac' uses `AM_MAINTAINER_MODE', which will disable all these rebuild rules by default. This is further discussed in *Note maintainer-mode::. * Although we focused on spurious rebuilds, the converse can also happen. CVS's timestamp handling can also let you think an out-of-date file is up-to-date. For instance, suppose a developer has modified `Makefile.am' and has rebuilt `Makefile.in'. He then decide to do a last-minute change to `Makefile.am' right before checking in both files (without rebuilding `Makefile.in' to account for the change). This last change to `Makefile.am' make the copy of `Makefile.in' out-of-date. Since CVS processes files alphabetically, when another developer `cvs update' his or her tree, `Makefile.in' will happen to be newer than `Makefile.am'. This other developer will not see `Makefile.in' is out-of-date. Generated files out of CVS .......................... One way to get CVS and `make' working peacefully is to never store generated files in CVS, i.e., do not CVS-control files that are `Makefile' targets (also called _derived_ files). This way developers are not annoyed by changes to generated files. It does not matter if they all have different versions (assuming they are compatible, of course). And finally, timestamps are not lost, changes to sources files can't be missed as in the `Makefile.am'/`Makefile.in' example discussed earlier. The drawback is that the CVS repository is not an exact copy of what is distributed and that users now need to install various development tools (maybe even specific versions) before they can build a checkout. But, after all, CVS's job is versioning, not distribution. Allowing developers to use different versions of their tools can also hide bugs during distributed development. Indeed, developers will be using (hence testing) their own generated files, instead of the generated files that will be released actually. The developer who prepares the tarball might be using a version of the tool that produces bogus output (for instance a non-portable C file), something other developers could have noticed if they weren't using their own versions of this tool. 27.1.4 Third-party files ------------------------ Another class of files not discussed here (because they do not cause timestamp issues) are files that are shipped with a package, but maintained elsewhere. For instance, tools like `gettextize' and `autopoint' (from Gettext) or `libtoolize' (from Libtool), will install or update files in your package. These files, whether they are kept under CVS or not, raise similar concerns about version mismatch between developers' tools. The Gettext manual has a section about this, see *Note CVS Issues: (gettext)CVS Issues.  File: automake.info, Node: maintainer-mode, Next: wildcards, Prev: CVS, Up: FAQ 27.2 `missing' and `AM_MAINTAINER_MODE' ======================================= 27.2.1 `missing' ---------------- The `missing' script is a wrapper around several maintainer tools, designed to warn users if a maintainer tool is required but missing. Typical maintainer tools are `autoconf', `automake', `bison', etc. Because file generated by these tools are shipped with the other sources of a package, these tools shouldn't be required during a user build and they are not checked for in `configure'. However, if for some reason a rebuild rule is triggered and involves a missing tool, `missing' will notice it and warn the user. Besides the warning, when a tool is missing, `missing' will attempt to fix timestamps in a way that allows the build to continue. For instance, `missing' will touch `configure' if `autoconf' is not installed. When all distributed files are kept under CVS, this feature of `missing' allows user _with no maintainer tools_ to build a package off CVS, bypassing any timestamp inconsistency implied by `cvs update'. If the required tool is installed, `missing' will run it and won't attempt to continue after failures. This is correct during development: developers love fixing failures. However, users with wrong versions of maintainer tools may get an error when the rebuild rule is spuriously triggered, halting the build. This failure to let the build continue is one of the arguments of the `AM_MAINTAINER_MODE' advocates. 27.2.2 `AM_MAINTAINER_MODE' --------------------------- `AM_MAINTAINER_MODE' disables the so called "rebuild rules" by default. If you have `AM_MAINTAINER_MODE' in `configure.ac', and run `./configure && make', then `make' will *never* attempt to rebuilt `configure', `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. If you run `./configure --enable-maintainer-mode', then these rebuild rules will be active. People use `AM_MAINTAINER_MODE' either because they do want their users (or themselves) annoyed by timestamps lossage (*note CVS::), or because they simply can't stand the rebuild rules and prefer running maintainer tools explicitly. `AM_MAINTAINER_MODE' also allows you to disable some custom build rules conditionally. Some developers use this feature to disable rules that need exotic tools that users may not have available. Several years ago Franc,ois Pinard pointed out several arguments against this `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 can be very confusing when unnoticed. He adds that security shouldn't be reserved to maintainers (what `--enable-maintainer-mode' suggests), on the contrary. If one user has to modify a `Makefile.am', then either `Makefile.in' should be updated or a warning should be output (this is what Automake uses `missing' for) but the last thing you want is that nothing happens and the user doesn't notice it (this is what happens when rebuild rules are disabled by `AM_MAINTAINER_MODE'). Jim Meyering, the inventor of the `AM_MAINTAINER_MODE' macro was swayed by Franc,ois's arguments, and got rid of `AM_MAINTAINER_MODE' in all of his packages. Still many people continue to use `AM_MAINTAINER_MODE', because it helps them working on projects where all files are kept under CVS, and because `missing' isn't enough if you have the wrong version of the tools.  File: automake.info, Node: wildcards, Next: limitations on file names, Prev: maintainer-mode, Up: FAQ 27.3 Why doesn't Automake support wildcards? ============================================ Developers are lazy. They often would like to use wildcards in `Makefile.am's, so they don't need to remember they have to update `Makefile.am's every time they add, delete, or rename a file. There are several objections to this: * When using CVS (or similar) developers need to remember they have to run `cvs add' or `cvs rm' anyway. Updating `Makefile.am' accordingly quickly becomes a reflex. Conversely, if your application doesn't compile because you forgot to add a file in `Makefile.am', it will help you remember to `cvs add' it. * Using wildcards makes easy to distribute files by mistake. For instance, some code a developer is experimenting with (a test case, say) but that should not be part of the distribution. * Using wildcards it's easy to omit some files by mistake. For instance, one developer creates a new file, uses it at many places, but forget to commit it. Another developer then checkout the incomplete project and is able to run `make dist' successfully, even though a file is missing. * Listing files, you control *exactly* what you distribute. If some file that should be distributed is missing from your tree, `make dist' will complain. Besides, you don't distribute more than what you listed. * Finally it's really hard to `forget' adding a file to `Makefile.am', because if you don't add it, it doesn't get compiled nor installed, so you can't even test it. Still, these are philosophical objections, and as such you may disagree, or find enough value in wildcards to dismiss all of them. Before you start writing a patch against Automake to teach it about wildcards, let's see the main technical issue: portability. Although `$(wildcard ...)' works with GNU `make', it is not portable to other `make' implementations. The only way Automake could support `$(wildcard ...)' is by expending `$(wildcard ...)' when `automake' is run. Resulting `Makefile.in's would be portable since they would list all files and not use `$(wildcard ...)'. However that means developers need to remember they must run `automake' each time they add, delete, or rename files. Compared to editing `Makefile.am', this is really little win. Sure, it's easier and faster to type `automake; make' than to type `emacs Makefile.am; make'. But nobody bothered enough to write a patch add support for this syntax. Some people use scripts to generated file lists in `Makefile.am' or in separate `Makefile' fragments. Even if you don't care about portability, and are tempted to use `$(wildcard ...)' anyway because you target only GNU Make, you should know there are many places where Automake need to know exactly which files should be processed. As Automake doesn't know how to expand `$(wildcard ...)', you cannot use it in these places. `$(wildcard ...)' is a black box comparable to `AC_SUBST'ed variables as far Automake is concerned. You can get warnings about `$(wildcard ...') constructs using the `-Wportability' flag.  File: automake.info, Node: limitations on file names, Next: distcleancheck, Prev: wildcards, Up: FAQ 27.4 Limitations on file names ============================== Automake attempts to support all kinds of file names, even those that contain unusual characters or are unusually long. However, some limitations are imposed by the underlying operating system and tools. Most operating systems prohibit the use of the null byte in file names, and reserve `/' as a directory separator. Also, they require that file names are properly encoded for the user's locale. Automake is subject to these limits. Portable packages should limit themselves to POSIX file names. These can contain ASCII letters and digits, `_', `.', and `-'. File names consist of components separated by `/'. File name components cannot begin with `-'. Portable POSIX file names cannot contain components that exceed a 14-byte limit, but nowadays it's normally safe to assume the more-generous XOPEN limit of 255 bytes. POSIX limits file names to 255 bytes (XOPEN allows 1023 bytes), but you may want to limit a source tarball to file names to 99 bytes to avoid interoperability problems with old versions of `tar'. If you depart from these rules (e.g., by using non-ASCII characters in file names, or by using lengthy file names), your installers may have problems for reasons unrelated to Automake. However, if this does not concern you, you should know about the limitations imposed by Automake itself. These limitations are undesirable, but some of them seem to be inherent to underlying tools like Autoconf, Make, M4, and the shell. They fall into three categories: install directories, build directories, and file names. The following characters: newline " # $ ' ` should not appear in the names of install directories. For example, the operand of `configure''s `--prefix' option should not contain these characters. Build directories suffer the same limitations as install directories, and in addition should not contain the following characters: & @ \ For example, the full name of the directory containing the source files should not contain these characters. Source and installation file names like `main.c' are limited even further: they should conform to the POSIX/XOPEN rules described above. In addition, if you plan to port to non-POSIX environments, you should avoid file names that differ only in case (e.g., `makefile' and `Makefile'). Nowadays it is no longer worth worrying about the 8.3 limits of DOS file systems.  File: automake.info, Node: distcleancheck, Next: Flag Variables Ordering, Prev: limitations on file names, Up: FAQ 27.5 Files left in build directory after distclean ================================================== This is a diagnostic you might encounter while running `make distcheck'. As explained in *Note Dist::, `make distcheck' attempts to build and check your package for errors like this one. `make distcheck' will perform a `VPATH' build of your package (*note VPATH Builds::), and then call `make distclean'. Files left in the build directory after `make distclean' has run are listed after this error. This diagnostic really covers two kinds of errors: * files that are forgotten by distclean; * distributed files that are erroneously rebuilt. The former left-over files are not distributed, so the fix is to mark them for cleaning (*note Clean::), this is obvious and doesn't deserve more explanations. The latter bug is not always easy to understand and fix, so let's proceed with an example. Suppose our package contains a program for which we want to build a man page using `help2man'. GNU `help2man' produces simple manual pages from the `--help' and `--version' output of other commands (*note Overview: (help2man)Top.). Because we don't to force want our users to install `help2man', we decide to distribute the generated man page using the following setup. # This Makefile.am is bogus. bin_PROGRAMS = foo foo_SOURCES = foo.c dist_man_MANS = foo.1 foo.1: foo$(EXEEXT) help2man --output=foo.1 ./foo$(EXEEXT) This will effectively distribute the man page. However, `make distcheck' will fail with: ERROR: files left in build directory after distclean: ./foo.1 Why was `foo.1' rebuilt? Because although distributed, `foo.1' depends on a non-distributed built file: `foo$(EXEEXT)'. `foo$(EXEEXT)' is built by the user, so it will always appear to be newer than the distributed `foo.1'. `make distcheck' caught an inconsistency in our package. Our intent was to distribute `foo.1' so users do not need installing `help2man', however since this our rule causes this file to be always rebuilt, users _do_ need `help2man'. Either we should ensure that `foo.1' is not rebuilt by users, or there is no point in distributing `foo.1'. More generally, the rule is that distributed files should never depend on non-distributed built files. If you distribute something generated, distribute its sources. One way to fix the above example, while still distributing `foo.1' is to not depend on `foo$(EXEEXT)'. For instance, assuming `foo --version' and `foo --help' do not change unless `foo.c' or `configure.ac' change, we could write the following `Makefile.am': bin_PROGRAMS = foo foo_SOURCES = foo.c dist_man_MANS = foo.1 foo.1: foo.c $(top_srcdir)/configure.ac $(MAKE) $(AM_MAKEFLAGS) foo$(EXEEXT) help2man --output=foo.1 ./foo$(EXEEXT) This way, `foo.1' will not get rebuilt every time `foo$(EXEEXT)' changes. The `make' call makes sure `foo$(EXEEXT)' is up-to-date before `help2man'. Another way to ensure this would be to use separate directories for binaries and man pages, and set `SUBDIRS' so that binaries are built before man pages. We could also decide not to distribute `foo.1'. In this case it's fine to have `foo.1' dependent upon `foo$(EXEEXT)', since both will have to be rebuilt. However it would be impossible to build the package in a cross-compilation, because building `foo.1' involves an _execution_ of `foo$(EXEEXT)'. Another context where such errors are common is when distributed files are built by tools that are built by the package. The pattern is similar: distributed-file: built-tools distributed-sources build-command should be changed to distributed-file: distributed-sources $(MAKE) $(AM_MAKEFLAGS) built-tools build-command or you could choose not to distribute `distributed-file', if cross-compilation does not matter. The points made through these examples are worth a summary: * Distributed files should never depend upon non-distributed built files. * Distributed files should be distributed with all their dependencies. * If a file is _intended_ to be rebuilt by users, then there is no point in distributing it. For desperate cases, it's always possible to disable this check by setting `distcleancheck_listfiles' as documented in *Note Dist::. Make sure you do understand the reason why `make distcheck' complains before you do this. `distcleancheck_listfiles' is a way to _hide_ errors, not to fix them. You can always do better.  File: automake.info, Node: Flag Variables Ordering, Next: renamed objects, Prev: distcleancheck, Up: FAQ 27.6 Flag Variables Ordering ============================ What is the difference between `AM_CFLAGS', `CFLAGS', and `mumble_CFLAGS'? Why does `automake' output `CPPFLAGS' after `AM_CPPFLAGS' on compile lines? Shouldn't it be the converse? My `configure' adds some warning flags into `CXXFLAGS'. In one `Makefile.am' I would like to append a new flag, however if I put the flag into `AM_CXXFLAGS' it is prepended to the other flags, not appended. 27.6.1 Compile Flag Variables ----------------------------- This section attempts to answer all the above questions. We will mostly discuss `CPPFLAGS' in our examples, but actually the answer holds for all the compile flags used in Automake: `CCASFLAGS', `CFLAGS', `CPPFLAGS', `CXXFLAGS', `FCFLAGS', `FFLAGS', `GCJFLAGS', `LDFLAGS', `LFLAGS', `LIBTOOLFLAGS', `OBJCFLAGS', `RFLAGS', `UPCFLAGS', and `YFLAGS'. `CPPFLAGS', `AM_CPPFLAGS', and `mumble_CPPFLAGS' are three variables that can be used to pass flags to the C preprocessor (actually these variables are also used for other languages like C++ or preprocessed Fortran). `CPPFLAGS' is the user variable (*note User Variables::), `AM_CPPFLAGS' is the Automake variable, and `mumble_CPPFLAGS' is the variable specific to the `mumble' target (we call this a per-target variable, *note Program and Library Variables::). Automake always uses two of these variables when compiling C sources files. When compiling an object file for the `mumble' target, the first variable will be `mumble_CPPFLAGS' if it is defined, or `AM_CPPFLAGS' otherwise. The second variable is always `CPPFLAGS'. In the following example, bin_PROGRAMS = foo bar foo_SOURCES = xyz.c bar_SOURCES = main.c foo_CPPFLAGS = -DFOO AM_CPPFLAGS = -DBAZ `xyz.o' will be compiled with `$(foo_CPPFLAGS) $(CPPFLAGS)', (because `xyz.o' is part of the `foo' target), while `main.o' will be compiled with `$(AM_CPPFLAGS) $(CPPFLAGS)' (because there is no per-target variable for target `bar'). The difference between `mumble_CPPFLAGS' and `AM_CPPFLAGS' being clear enough, let's focus on `CPPFLAGS'. `CPPFLAGS' is a user variable, i.e., a variable that users are entitled to modify in order to compile the package. This variable, like many others, is documented at the end of the output of `configure --help'. For instance, someone who needs to add `/home/my/usr/include' to the C compiler's search path would configure a package with ./configure CPPFLAGS='-I /home/my/usr/include' and this flag would be propagated to the compile rules of all `Makefile's. It is also not uncommon to override a user variable at `make'-time. Many installers do this with `prefix', but this can be useful with compiler flags too. For instance, if, while debugging a C++ project, you need to disable optimization in one specific object file, you can run something like rm file.o make CXXFLAGS=-O0 file.o make The reason `$(CPPFLAGS)' appears after `$(AM_CPPFLAGS)' or `$(mumble_CPPFLAGS)' in the compile command is that users should always have the last say. It probably makes more sense if you think about it while looking at the `CXXFLAGS=-O0' above, which should supersede any other switch from `AM_CXXFLAGS' or `mumble_CXXFLAGS' (and this of course replaces the previous value of `CXXFLAGS'). You should never redefine a user variable such as `CPPFLAGS' in `Makefile.am'. Use `automake -Woverride' to diagnose such mistakes. Even something like CPPFLAGS = -DDATADIR=\"$(datadir)\" @CPPFLAGS@ is erroneous. Although this preserves `configure''s value of `CPPFLAGS', the definition of `DATADIR' will disappear if a user attempts to override `CPPFLAGS' from the `make' command line. AM_CPPFLAGS = -DDATADIR=\"$(datadir)\" is all what is needed here if no per-target flags are used. You should not add options to these user variables within `configure' either, for the same reason. Occasionally you need to modify these variables to perform a test, but you should reset their values afterwards. In contrast, it is OK to modify the `AM_' variables within `configure' if you `AC_SUBST' them, but it is rather rare that you need to do this, unless you really want to change the default definitions of the `AM_' variables in all `Makefile's. What we recommend is that you define extra flags in separate variables. For instance, you may write an Autoconf macro that computes a set of warning options for the C compiler, and `AC_SUBST' them in `WARNINGCFLAGS'; you may also have an Autoconf macro that determines which compiler and which linker flags should be used to link with library `libfoo', and `AC_SUBST' these in `LIBFOOCFLAGS' and `LIBFOOLDFLAGS'. Then, a `Makefile.am' could use these variables as follows: AM_CFLAGS = $(WARNINGCFLAGS) bin_PROGRAMS = prog1 prog2 prog1_SOURCES = ... prog2_SOURCES = ... prog2_CFLAGS = $(LIBFOOCFLAGS) $(AM_CFLAGS) prog2_LDFLAGS = $(LIBFOOLDFLAGS) In this example both programs will be compiled with the flags substituted into `$(WARNINGCFLAGS)', and `prog2' will additionally be compiled with the flags required to link with `libfoo'. Note that listing `AM_CFLAGS' in a per-target `CFLAGS' variable is a common idiom to ensure that `AM_CFLAGS' applies to every target in a `Makefile.in'. Using variables like this gives you full control over the ordering of the flags. For instance, if there is a flag in $(WARNINGCFLAGS) that you want to negate for a particular target, you can use something like `prog1_CFLAGS = $(AM_CFLAGS) -no-flag'. If all these flags had been forcefully appended to `CFLAGS', there would be no way to disable one flag. Yet another reason to leave user variables to users. Finally, we have avoided naming the variable of the example `LIBFOO_LDFLAGS' (with an underscore) because that would cause Automake to think that this is actually a per-target variable (like `mumble_LDFLAGS') for some non-declared `LIBFOO' target. 27.6.2 Other Variables ---------------------- There are other variables in Automake that follow similar principles to allow user options. For instance, Texinfo rules (*note Texinfo::) use `MAKEINFOFLAGS' and `AM_MAKEINFOFLAGS'. Similarly, DejaGnu tests (*note Tests::) use `RUNTESTDEFAULTFLAGS' and `AM_RUNTESTDEFAULTFLAGS'. The tags and ctags rules (*note Tags::) use `ETAGSFLAGS', `AM_ETAGSFLAGS', `CTAGSFLAGS', and `AM_CTAGSFLAGS'. Java rules (*note Java::) use `JAVACFLAGS' and `AM_JAVACFLAGS'. None of these rules do support per-target flags (yet). To some extent, even `AM_MAKEFLAGS' (*note Subdirectories::) obeys this naming scheme. The slight difference is that `MAKEFLAGS' is passed to sub-`make's implicitly by `make' itself. However you should not think that all variables ending with `FLAGS' follow this convention. For instance, `DISTCHECK_CONFIGURE_FLAGS' (*note Dist::), `ACLOCAL_AMFLAGS' (see *Note Rebuilding:: and *Note Local Macros::), are two variables that are only useful to the maintainer and have no user counterpart. `ARFLAGS' (*note A Library::) is usually defined by Automake and has neither `AM_' nor per-target cousin. Finally you should not think either that the existence of a per-target variable implies that of an `AM_' variable or that of a user variable. For instance, the `mumble_LDADD' per-target variable overrides the global `LDADD' variable (which is not a user variable), and `mumble_LIBADD' exists only as a per-target variable. *Note Program and Library Variables::.  File: automake.info, Node: renamed objects, Next: Per-Object Flags, Prev: Flag Variables Ordering, Up: FAQ 27.7 Why are object files sometimes renamed? ============================================ This happens when per-target compilation flags are used. Object files need to be renamed just in case they would clash with object files compiled from the same sources, but with different flags. Consider the following example. bin_PROGRAMS = true false true_SOURCES = generic.c true_CPPFLAGS = -DEXIT_CODE=0 false_SOURCES = generic.c false_CPPFLAGS = -DEXIT_CODE=1 Obviously the two programs are built from the same source, but it would be bad if they shared the same object, because `generic.o' cannot be built with both `-DEXIT_CODE=0' _and_ `-DEXIT_CODE=1'. Therefore `automake' outputs rules to build two different objects: `true-generic.o' and `false-generic.o'. `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. It's OK to share object files when per-target compilation flags are not used. For instance, `true' and `false' will both use `version.o' in the following example. AM_CPPFLAGS = -DVERSION=1.0 bin_PROGRAMS = true false true_SOURCES = true.c version.c false_SOURCES = false.c version.c Note that the renaming of objects is also affected by the `_SHORTNAME' variable (*note Program and Library Variables::).  File: automake.info, Node: Per-Object Flags, Next: Multiple Outputs, Prev: renamed objects, Up: FAQ 27.8 Per-Object Flags Emulation =============================== One of my source files needs to be compiled with different flags. How do I do? Automake supports per-program and per-library compilation flags (see *Note Program and Library Variables:: and *Note Flag Variables Ordering::). With this you can define compilation flags that apply to all files compiled for a target. For instance, in bin_PROGRAMS = foo foo_SOURCES = foo.c foo.h bar.c bar.h main.c foo_CFLAGS = -some -flags `foo-foo.o', `foo-bar.o', and `foo-main.o' will all be compiled with `-some -flags'. (If you wonder about the names of these object files, see *Note renamed objects::.) Note that `foo_CFLAGS' gives the flags to use when compiling all the C sources of the _program_ `foo', it has nothing to do with `foo.c' or `foo-foo.o' specifically. What if `foo.c' needs to be compiled into `foo.o' using some specific flags, that none of the other files require? Obviously per-program flags are not directly applicable here. Something like per-object flags are expected, i.e., flags that would be used only when creating `foo-foo.o'. Automake does not support that, however this is easy to simulate using a library that contains only that object, and compiling this library with per-library flags. bin_PROGRAMS = foo foo_SOURCES = bar.c bar.h main.c foo_CFLAGS = -some -flags foo_LDADD = libfoo.a noinst_LIBRARIES = libfoo.a libfoo_a_SOURCES = foo.c foo.h libfoo_a_CFLAGS = -some -other -flags Here `foo-bar.o' and `foo-main.o' will all be compiled with `-some -flags', while `libfoo_a-foo.o' will be compiled using `-some -other -flags'. Eventually, all three objects will be linked to form `foo'. This trick can also be achieved using Libtool convenience libraries, for instance `noinst_LTLIBRARIES = libfoo.la' (*note Libtool Convenience Libraries::). Another tempting idea to implement per-object flags is to override the compile rules `automake' would output for these files. Automake will not define a rule for a target you have defined, so you could think about defining the `foo-foo.o: foo.c' rule yourself. We recommend against this, because this is error prone. For instance, if you add such a rule to the first example, it will break the day you decide to remove `foo_CFLAGS' (because `foo.c' will then be compiled as `foo.o' instead of `foo-foo.o', *note renamed objects::). Also in order to support dependency tracking, the two `.o'/`.obj' extensions, and all the other flags variables involved in a compilation, you will end up modifying a copy of the rule previously output by `automake' for this file. If a new release of Automake generates a different rule, your copy will need to be updated by hand.  File: automake.info, Node: Multiple Outputs, Next: Hard-Coded Install Paths, Prev: Per-Object Flags, Up: FAQ 27.9 Handling Tools that Produce Many Outputs ============================================= This section describes a `make' idiom that can be used when a tool produces multiple output files. It is not specific to Automake and can be used in ordinary `Makefile's. Suppose we have a program called `foo' that will read one file called `data.foo' and produce two files named `data.c' and `data.h'. We want to write a `Makefile' rule that captures this one-to-two dependency. The naive rule is incorrect: # This is incorrect. data.c data.h: data.foo foo data.foo What the above rule really says is that `data.c' and `data.h' each depend on `data.foo', and can each be built by running `foo data.foo'. In other words it is equivalent to: # We do not want this. data.c: data.foo foo data.foo data.h: data.foo foo data.foo which means that `foo' can be run twice. Usually it will not be run twice, because `make' implementations are smart enough to check for the existence of the second file after the first one has been built; they will therefore detect that it already exists. However there are a few situations where it can run twice anyway: * The most worrying case is when running a parallel `make'. If `data.c' and `data.h' are built in parallel, two `foo data.foo' commands will run concurrently. This is harmful. * Another case is when the dependency (here `data.foo') is (or depends upon) a phony target. A solution that works with parallel `make' but not with phony dependencies is the following: data.c data.h: data.foo foo data.foo data.h: data.c The above rules are equivalent to data.c: data.foo foo data.foo data.h: data.foo data.c foo data.foo therefore a parallel `make' will have to serialize the builds of `data.c' and `data.h', and will detect that the second is no longer needed once the first is over. Using this pattern is probably enough for most cases. However it does not scale easily to more output files (in this scheme all output files must be totally ordered by the dependency relation), so we will explore a more complicated solution. Another idea is to write the following: # There is still a problem with this one. data.c: data.foo foo data.foo data.h: data.c The idea is that `foo data.foo' is run only when `data.c' needs to be updated, but we further state that `data.h' depends upon `data.c'. That way, if `data.h' is required and `data.foo' is out of date, the dependency on `data.c' will trigger the build. This is almost perfect, but suppose we have built `data.h' and `data.c', and then we erase `data.h'. Then, running `make data.h' will not rebuild `data.h'. The above rules just state that `data.c' must be up-to-date with respect to `data.foo', and this is already the case. What we need is a rule that forces a rebuild when `data.h' is missing. Here it is: data.c: data.foo foo data.foo data.h: data.c ## Recover from the removal of $@ @if test -f $@; then :; else \ rm -f data.c; \ $(MAKE) $(AM_MAKEFLAGS) data.c; \ fi The above scheme can be extended to handle more outputs and more inputs. One of the outputs is selected to serve as a witness to the successful completion of the command, it depends upon all inputs, and all other outputs depend upon it. For instance, if `foo' should additionally read `data.bar' and also produce `data.w' and `data.x', we would write: data.c: data.foo data.bar foo data.foo data.bar data.h data.w data.x: data.c ## Recover from the removal of $@ @if test -f $@; then :; else \ rm -f data.c; \ $(MAKE) $(AM_MAKEFLAGS) data.c; \ fi However there are now two minor problems in this setup. One is related to the timestamp ordering of `data.h', `data.w', `data.x', and `data.c'. The other one is a race condition if a parallel `make' attempts to run multiple instances of the recover block at once. Let us deal with the first problem. `foo' outputs four files, but we do not know in which order these files are created. Suppose that `data.h' is created before `data.c'. Then we have a weird situation. The next time `make' is run, `data.h' will appear older than `data.c', the second rule will be triggered, a shell will be started to execute the `if...fi' command, but actually it will just execute the `then' branch, that is: nothing. In other words, because the witness we selected is not the first file created by `foo', `make' will start a shell to do nothing each time it is run. A simple riposte is to fix the timestamps when this happens. data.c: data.foo data.bar foo data.foo data.bar data.h data.w data.x: data.c @if test -f $@; then \ touch $@; \ else \ ## Recover from the removal of $@ rm -f data.c; \ $(MAKE) $(AM_MAKEFLAGS) data.c; \ fi Another solution is to use a different and dedicated file as witness, rather than using any of `foo''s outputs. data.stamp: data.foo data.bar @rm -f data.tmp @touch data.tmp foo data.foo data.bar @mv -f data.tmp $@ data.c data.h data.w data.x: data.stamp ## Recover from the removal of $@ @if test -f $@; then :; else \ rm -f data.stamp; \ $(MAKE) $(AM_MAKEFLAGS) data.stamp; \ fi `data.tmp' is created before `foo' is run, so it has a timestamp older than output files output by `foo'. It is then renamed to `data.stamp' after `foo' has run, because we do not want to update `data.stamp' if `foo' fails. This solution still suffers from the second problem: the race condition in the recover rule. If, after a successful build, a user erases `data.c' and `data.h', and runs `make -j', then `make' may start both recover rules in parallel. If the two instances of the rule execute `$(MAKE) $(AM_MAKEFLAGS) data.stamp' concurrently the build is likely to fail (for instance, the two rules will create `data.tmp', but only one can rename it). Admittedly, such a weird situation does not arise during ordinary builds. It occurs only when the build tree is mutilated. Here `data.c' and `data.h' have been explicitly removed without also removing `data.stamp' and the other output files. `make clean; make' will always recover from these situations even with parallel makes, so you may decide that the recover rule is solely to help non-parallel make users and leave things as-is. Fixing this requires some locking mechanism to ensure only one instance of the recover rule rebuilds `data.stamp'. One could imagine something along the following lines. data.c data.h data.w data.x: data.stamp ## Recover from the removal of $@ @if test -f $@; then :; else \ trap 'rm -rf data.lock data.stamp 1 2 13 15; \ ## mkdir is a portable test-and-set if mkdir data.lock 2>/dev/null; then \ ## This code is being executed by the first process. rm -f data.stamp; \ $(MAKE) $(AM_MAKEFLAGS) data.stamp; \ else \ ## This code is being executed by the follower processes. ## Wait until the first process is done. while test -d data.lock; do sleep 1; done; \ ## Succeed if and only if the first process succeeded. test -f data.stamp; exit $$?; \ fi; \ fi Using a dedicated witness, like `data.stamp', is very handy when the list of output files is not known beforehand. As an illustration, consider the following rules to compile many `*.el' files into `*.elc' files in a single command. It does not matter how `ELFILES' is defined (as long as it is not empty: empty targets are not accepted by POSIX). ELFILES = one.el two.el three.el ... ELCFILES = $(ELFILES:=c) elc-stamp: $(ELFILES) @rm -f elc-temp @touch elc-temp $(elisp_comp) $(ELFILES) @mv -f elc-temp $@ $(ELCFILES): elc-stamp ## Recover from the removal of $@ @if test -f $@; then :; else \ trap 'rm -rf elc-lock elc-stamp' 1 2 13 15; \ if mkdir elc-lock 2>/dev/null; then \ ## This code is being executed by the first process. rm -f elc-stamp; \ $(MAKE) $(AM_MAKEFLAGS) elc-stamp; \ rmdir elc-lock; \ else \ ## This code is being executed by the follower processes. ## Wait until the first process is done. while test -d elc-lock; do sleep 1; done; \ ## Succeed if and only if the first process succeeded. test -f elc-stamp; exit $$?; \ fi; \ fi For completeness it should be noted that GNU `make' is able to express rules with multiple output files using pattern rules (*note Pattern Rule Examples: (make)Pattern Examples.). We do not discuss pattern rules here because they are not portable, but they can be convenient in packages that assume GNU `make'.  File: automake.info, Node: Hard-Coded Install Paths, Prev: Multiple Outputs, Up: FAQ 27.10 Installing to Hard-Coded Locations ======================================== My package needs to install some configuration file. I tried to use the following rule, but `make distcheck' fails. Why? # Do not do this. install-data-local: $(INSTALL_DATA) $(srcdir)/afile $(DESTDIR)/etc/afile My package needs to populate the installation directory of another package at install-time. I can easily compute that installation directory in `configure', but if I install files therein, `make distcheck' fails. How else should I do? These two setups share their symptoms: `make distcheck' fails because they are installing files to hard-coded paths. In the later case the path is not really hard-coded in the package, but we can consider it to be hard-coded in the system (or in whichever tool that supplies the path). As long as the path does not use any of the standard directory variables (`$(prefix)', `$(bindir)', `$(datadir)', etc.), the effect will be the same: user-installations are impossible. When a (non-root) user wants to install a package, he usually has no right to install anything in `/usr' or `/usr/local'. So he does something like `./configure --prefix ~/usr' to install package in his own `~/usr' tree. If a package attempts to install something to some hard-coded path (e.g., `/etc/afile'), regardless of this `--prefix' setting, then the installation will fail. `make distcheck' performs such a `--prefix' installation, hence it will fail too. Now, there are some easy solutions. The above `install-data-local' example for installing `/etc/afile' would be better replaced by sysconf_DATA = afile by default `sysconfdir' will be `$(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 `--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 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 where to install the library, it will answer something like this: % python -c 'from distutils import sysconfig; print sysconfig.get_python_lib(1,0)' /usr/lib/python2.3/site-packages If you indeed use this absolute path to install your shared library, non-root users will not be able to install the package, hence distcheck fails. Let's do better. The `sysconfig.get_python_lib()' function actually accepts a third argument that will replace Python's installation prefix. % python -c 'from distutils import sysconfig; print sysconfig.get_python_lib(1,0,"${exec_prefix}")' ${exec_prefix}/lib/python2.3/site-packages You can also use this new path. If you do * root users can install your package with the same `--prefix' as Python (you get the behavior of the previous attempt) * non-root users can install your package too, they will have the extension module in a place that is not searched by Python but they can work around this using environment variables (and if you installed scripts that use this shared library, it's easy to tell Python were to look in the beginning of your script, so the script works in both cases). The `AM_PATH_PYTHON' macro uses similar commands to define `$(pythondir)' and `$(pyexecdir)' (*note Python::). Of course not all tools are as advanced as Python regarding that substitution of PREFIX. So another strategy is to figure the part of the of the installation directory that must be preserved. For instance, here is how `AM_PATH_LISPDIR' (*note Emacs Lisp::) computes `$(lispdir)': $EMACS -batch -q -eval '(while load-path (princ (concat (car load-path) "\n")) (setq load-path (cdr load-path)))' >conftest.out lispdir=`sed -n -e 's,/$,,' -e '/.*\/lib\/x*emacs\/site-lisp$/{ s,.*/lib/\(x*emacs/site-lisp\)$,${libdir}/\1,;p;q; }' -e '/.*\/share\/x*emacs\/site-lisp$/{ s,.*/share/\(x*emacs/site-lisp\),${datarootdir}/\1,;p;q; }' conftest.out` I.e., it just picks the first directory that looks like `*/lib/*emacs/site-lisp' or `*/share/*emacs/site-lisp' in the search path of emacs, and then substitutes `${libdir}' or `${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 non-root users are really worth the extra `sed' invocation.  File: automake.info, Node: History, Next: Copying This Manual, Prev: FAQ, Up: Top 28 History of Automake ********************** This chapter presents various aspects of the history of Automake. The exhausted reader can safely skip it; this will be more of interest to nostalgic people, or to those curious to learn about the evolution of Automake. * Menu: * Timeline:: The Automake story. * Dependency Tracking Evolution:: Evolution of Automatic Dependency Tracking * Releases:: Statistics about Automake Releases  File: automake.info, Node: Timeline, Next: Dependency Tracking Evolution, Up: History 28.1 Timeline ============= 1994-09-19 First CVS commit. If we can trust the CVS repository, David J. MacKenzie (djm) started working on Automake (or AutoMake, as it was spelt then) this Monday. The first version of the `automake' script looks as follows. #!/bin/sh status=0 for makefile do if test ! -f ${makefile}.am; then echo "automake: ${makefile}.am: No such honkin' file" status=1 continue fi exec 4> ${makefile}.in done From this you can already see that Automake will be about reading `*.am' file and producing `*.in' files. You cannot see anything else, but if you also know that David is the one who created Autoconf two years before you can guess the rest. Several commits follow, and by the end of the day Automake is reported to work for GNU fileutils and GNU m4. The modus operandi is the one that is still used today: variables assignments in `Makefile.am' files trigger injections of precanned `Makefile' fragments into the generated `Makefile.in'. The use of `Makefile' fragments was inspired by the 4.4BSD `make' and include files, however Automake aims to be portable and to conform to the GNU standards for `Makefile' variables and targets. At this point, the most recent release of Autoconf is version 1.11, and David is preparing to release Autoconf 2.0 in late October. As a matter of fact, he will barely touch Automake after September. 1994-11-05 David MacKenzie's last commit. At this point Automake is a 200 line portable shell script, plus 332 lines of `Makefile' fragments. In the `README', David states his ambivalence between "portable shell" and "more appropriate language": I wrote it keeping in mind the possibility of it becoming an Autoconf macro, so it would run at configure-time. That would slow configuration down a bit, but allow users to modify the Makefile.am without needing to fetch the AutoMake package. And, the Makefile.in files wouldn't need to be distributed. But all of AutoMake would. So I might reimplement AutoMake in Perl, m4, or some other more appropriate language. Automake is described as "an experimental Makefile generator". There is no documentation. Adventurous users are referred to the examples and patches needed to use Automake with GNU m4 1.3, fileutils 3.9, time 1.6, and development versions of find and indent. These examples seem to have been lost. However at the time of writing (10 years later in September, 2004) the FSF still distributes a package that uses this version of Automake: check out GNU termutils 2.0. 1995-11-12 Tom Tromey's first commit. After one year of inactivity, Tom Tromey takes over the package. Tom was working on GNU cpio back then, and doing this just for fun, having trouble finding a project to contribute to. So while hacking he wanted to bring the `Makefile.in' up to GNU standards. This was hard, and one day he saw Automake on `ftp://alpha.gnu.org/', grabbed it and tried it out. Tom didn't talk to djm about it until later, just to make sure he didn't mind if he made a release. He did a bunch of early releases to the Gnits folks. Gnits was (and still is) totally informal, just a few GNU friends who Franc,ois Pinard knew, who were all interested in making a common infrastructure for GNU projects, and shared a similar outlook on how to do it. So they were able to make some progress. It came along with Autoconf and extensions thereof, and then Automake from David and Tom (who were both gnitsians). One of their ideas was to write a document paralleling the GNU standards, that was more strict in some ways and more detailed. They never finished the GNITS standards, but the ideas mostly made their way into Automake. 1995-11-23 Automake 0.20 Besides introducing automatic dependency tracking (*note Dependency Tracking Evolution::), this version also supplies a 9-page manual. At this time `aclocal' and `AM_INIT_AUTOMAKE' did not exist, so many things had to be done by hand. For instance, here is what a configure.in (this is the former name of the `configure.ac' we use today) must contain in order to use Automake 0.20: PACKAGE=cpio VERSION=2.3.911 AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE") AC_DEFINE_UNQUOTED(VERSION, "$VERSION") AC_SUBST(PACKAGE) AC_SUBST(VERSION) AC_ARG_PROGRAM AC_PROG_INSTALL (Today all of the above is achieved by `AC_INIT' and `AM_INIT_AUTOMAKE'.) Here is how programs are specified in `Makefile.am': PROGRAMS = hello hello_SOURCES = hello.c This looks pretty much like what we do today, except the `PROGRAMS' variable has no directory prefix specifying where `hello' should be installed: all programs are installed in `$(bindir)'. `LIBPROGRAMS' can be used to specify programs that must be built but not installed (it is called `noinst_PROGRAMS' nowadays). Programs can be built conditionally using `AC_SUBST'itutions: PROGRAMS = @progs@ AM_PROGRAMS = foo bar baz (`AM_PROGRAMS' has since then been renamed to `EXTRA_PROGRAMS'.) Similarly scripts, static libraries, and data can built and installed using the `LIBRARIES', `SCRIPTS', and `DATA' variables. However `LIBRARIES' were treated a bit specially in that Automake did automatically supply the `lib' and `.a' prefixes. Therefore to build `libcpio.a', one had to write LIBRARIES = cpio cpio_SOURCES = ... Extra files to distribute must be listed in `DIST_OTHER' (the ancestor of `EXTRA_DIST'). Also extra directories that are to be distributed should appear in `DIST_SUBDIRS', but the manual describes this as a temporary ugly hack (today extra directories should also be listed in `EXTRA_DIST', and `DIST_SUBDIRS' is used for another purpose, *note Conditional Subdirectories::). 1995-11-26 Automake 0.21 In less time that 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. If you never used Perl 4, imagine Perl 5 without objects, without `my' variables (only dynamically scoped `local' variables), without function prototypes, with function calls that needs to be prefixed with `&', etc. Traces of this old style can still be found in today's `automake'. 1995-11-28 Automake 0.22 1995-11-29 Automake 0.23 Bug fixes. 1995-12-08 Automake 0.24 1995-12-10 Automake 0.25 Releases are raining. 0.24 introduces the uniform naming scheme we use today, i.e., `bin_PROGRAMS' instead of `PROGRAMS', `noinst_LIBRARIES' instead of `LIBLIBRARIES', etc. (However `EXTRA_PROGRAMS' does not exist yet, `AM_PROGRAMS' is still in use; and `TEXINFOS' and `MANS' still have no directory prefixes.) Adding support for prefixes like that was one of the major ideas in automake; it has lasted pretty well. AutoMake is renamed to Automake (Tom seems to recall it was Franc,ois Pinard's doing). 0.25 fixes a Perl 4 portability bug. 1995-12-18 Jim Meyering starts using Automake in GNU Textutils. 1995-12-31 Franc,ois Pinard starts using Automake in GNU tar. 1996-01-03 Automake 0.26 1996-01-03 Automake 0.27 Of the many change and suggestions sent by Franc,ois Pinard and included in 0.26, the most important is perhaps the advise that to ease customization a user rule or variable definition should always override an Automake rule or definition. Gordon Matzigkeit and Jim Meyering are two other early contributors that have been sending fixes. 0.27 fixes yet another Perl 4 portability bug. 1996-01-13 Automake 0.28 Automake starts scanning `configure.in' for `LIBOBJS' support. This is an important step because until this version Automake did only know about the `Makefile.am's it processed. `configure.in' was Autoconf's world and the link between Autoconf and Automake had to be done by the `Makefile.am' author. For instance, if `config.h' was generated by `configure', it was the package maintainer's responsibility to define the `CONFIG_HEADER' variable in each `Makefile.am'. Succeeding releases will rely more and more on scanning `configure.in' to better automate the Autoconf integration. 0.28 also introduces the `AUTOMAKE_OPTIONS' variable and the `--gnu' and `--gnits' options, the latter being stricter. 1996-02-07 Automake 0.29 Thanks to `configure.in' scanning, `CONFIG_HEADER' is gone, and rebuild rules for `configure'-generated file are automatically output. `TEXINFOS' and `MANS' converted to the uniform naming scheme. 1996-02-24 Automake 0.30 The test suite is born. It contains 9 tests. From now on test cases will be added pretty regularly (*note Releases::), and this proved to be really helpful later on. `EXTRA_PROGRAMS' finally replaces `AM_PROGRAMS'. All the third-party Autoconf macros, written mostly by Franc,ois Pinard (and later Jim Meyering), are distributed in Automake's hand-written `aclocal.m4' file. Package maintainers are expected to extract the necessary macros from this file. (In previous version you had to copy and paste them from the manual...) 1996-03-11 Automake 0.31 The test suite in 0.30 was run via a long `check-local' rule. Upon Ulrich Drepper's suggestion, 0.31 makes it an Automake rule output whenever the `TESTS' variable is defined. `DIST_OTHER' is renamed to `EXTRA_DIST', and the `check_' prefix is introduced. The syntax is now the same as today. 1996-03-15 Gordon Matzigkeit starts writing libtool. 1996-04-27 Automake 0.32 `-hook' targets are introduced; an idea from Dieter Baron. `*.info' files, which were output in the build directory are now built in the source directory, because they are distributed. It seems these files like to move back and forth as that will happen again in future versions. 1996-05-18 Automake 0.33 Gord Matzigkeit's main two contributions: * very preliminary libtool support * the distcheck rule Although they were very basic at this point, these are probably among the top features for Automake today. Jim Meyering also provides the infamous `jm_MAINTAINER_MODE', since then renamed to `AM_MAINTAINER_MODE' and abandoned by its author (*note maintainer-mode::). 1996-05-28 Automake 1.0 After only six months of heavy development, the automake script is 3134 lines long, plus 973 lines of `Makefile' fragments. The package has 30 pages of documentation, and 38 test cases. `aclocal.m4' contains 4 macros. From now on and until version 1.4, new releases will occur at a rate of about one a year. 1.1 did not exist, actually 1.1b to 1.1p have been the name of beta releases for 1.2. This is the first time Automake uses suffix letters to designate beta releases, an habit that lasts. 1996-10-10 Kevin Dalley packages Automake 1.0 for Debian GNU/Linux. 1996-11-26 David J. MacKenzie releases Autoconf 2.12. Between June and October, the Autoconf development is almost staled. Roland McGrath has been working at the beginning of the year. David comes back in November to release 2.12, but he won't touch Autoconf anymore after this year, and Autoconf then really stagnates. The desolate Autoconf `ChangeLog' for 1997 lists only 7 commits. 1997-02-28 list alive The mailing list is announced as follows: I've created the "automake" mailing list. It is "automake@gnu.ai.mit.edu". Administrivia, as always, to automake-request@gnu.ai.mit.edu. The charter of this list is discussion of automake, autoconf, and other configuration/portability tools (e.g., libtool). It is expected that discussion will range from pleas for help all the way up to patches. This list is archived on the FSF machines. Offhand I don't know if you can get the archive without an account there. This list is open to anybody who wants to join. Tell all your friends! -- Tom Tromey Before that people were discussing Automake privately, on the Gnits mailing list (which is not public either), and less frequently on `gnu.misc.discuss'. `gnu.ai.mit.edu' is now `gnu.org', in case you never noticed. The archives of the early years of the `automake@gnu.org' list have been lost, so today it is almost impossible to find traces of discussions that occurred before 1999. This has been annoying more than once, as such discussions can be useful to understand the rationale behind a piece of uncommented code that was introduced back then. 1997-06-22 Automake 1.2 Automake developments continues, and more and more new Autoconf macros are required. Distributing them in `aclocal.m4' and requiring people to browse this file to extract the relevant macros becomes uncomfortable. Ideally, some of them should be contributed to Autoconf so that they can be used directly, however Autoconf is currently inactive. Automake 1.2 consequently introduces `aclocal' (`aclocal' was actually started on 1996-07-28), a tool that automatically constructs an `aclocal.m4' file from a repository of third-party macros. Because Autoconf has stalled, Automake also becomes a kind of repository for such third-party macros, even macros completely unrelated to Automake (for instance macros that fix broken Autoconf macros). The 1.2 release contains 20 macros, among which the `AM_INIT_AUTOMAKE' macro that simplifies the creation of `configure.in'. Libtool is fully supported using `*_LTLIBRARIES'. The missing script is introduced by Franc,ois Pinard; it is meant to be a better solution than `AM_MAINTAINER_MODE' (*note maintainer-mode::). Conditionals support was implemented by Ian Lance Taylor. At the time, Tom and Ian were working on an internal project at Cygnus. They were using ILU, which is pretty similar to CORBA. They wanted to integrate ILU into their build, which was all `configure'-based, and Ian thought that adding conditionals to `automake' was simpler than doing all the work in `configure' (which was the standard at the time). So this was actually funded by Cygnus. This very useful but tricky feature will take a lot of time to stabilize. (At the time this text is written, there are still primaries that have not been updated to support conditional definitions in Automake 1.9.) The `automake' script has almost doubled: 6089 lines of Perl, plus 1294 lines of `Makefile' fragments. 1997-07-08 Gordon Matzigkeit releases Libtool 1.0. 1998-04-05 Automake 1.3 This is a small advance compared to 1.2. It add support for assembly, and preliminary support for Java. Perl 5.004_04 is out, but fixes to support Perl 4 are still regularly submitted whenever Automake breaks it. 1998-09-06 `sourceware.cygnus.com' is on-line. Sourceware was setup by Jason Molenda to host open source projects. 1998-09-19 Automake CVS repository moved to `sourceware.cygnus.com' 1998-10-26 `sourceware.cygnus.com' announces it hosts Automake Automake is now hosted on `sourceware.cygnus.com'. It has a publicly accessible CVS repository. This CVS repository is a copy of the one Tom was using on his machine, which in turn is based on a copy of the CVS repository of David MacKenzie. This is why we still have to full source history. (Automake is still on Sourceware today, but the host has been renamed to `sources.redhat.com'.) The oldest file in the administrative directory of the CVS repository that was created on Sourceware is dated 1998-09-19, while the announcement that `automake' and `autoconf' had joined `sourceware' was made on 1998-10-26. They were among the first projects to be hosted there. The heedful reader will have noticed Automake was exactly 4-year-old on 1998-09-19. 1999-01-05 Ben Elliston releases Autoconf 2.13. 1999-01-14 Automake 1.4 This release adds support for Fortran 77 and for the `include' statement. Also, `+=' assignments are introduced, but it is still quite easy to fool Automake when mixing this with conditionals. These two releases, Automake 1.4 and Autoconf 2.13 makes a duo that will be used together for years. `automake' is 7228 lines, plus 1591 lines of Makefile fragment, 20 macros (some 1.3 macros were finally contributed back to Autoconf), 197 test cases, and 51 pages of documentation. 1999-03-27 The `user-dep-branch' is created on the CVS repository. This implements a new dependency tracking schemed that should be able to handle automatic dependency tracking using any compiler (not just gcc) and any make (not just GNU `make'). In addition, the new scheme should be more reliable than the old one, as dependencies are generated on the end user's machine. Alexandre Oliva creates depcomp for this purpose. *Note Dependency Tracking Evolution::, for more details about the evolution of automatic dependency tracking in Automake. 1999-11-21 The `user-dep-branch' is merged into the main trunk. This was a huge problem since we also had patches going in on the trunk. The merge took a long time and was very painful. 2000-05-10 Since September 1999 and until 2003, Akim Demaille will be zealously revamping Autoconf. I think the next release should be called "3.0". Let's face it: you've basically rewritten autoconf. Every weekend there are 30 new patches. I don't see how we could call this "2.15" with a straight face. - Tom Tromey on Actually Akim works like a submarine: he will pile up patches while he works off-line during the weekend, and flush them in batch when he resurfaces on Monday. 2001-01-24 On this Wednesday, Autoconf 2.49c, the last beta before Autoconf 2.50 is out, and Akim has to find something to do during his week-end :) 2001-01-28 Akim sends a batch of 14 patches to . Aiieeee! I was dreading the day that the Demaillator turned his sights on automake... and now it has arrived! - Tom Tromey It's only the beginning: in two months he will send 192 patches. Then he would slow down so Tom can catch up and review all this. Initially Tom actually read all these patches, then he probably trustingly answered OK to most of them, and finally gave up and let Akim apply whatever he wanted. There was no way to keep up with that patch rate. Anyway the patch below won't apply since it predates Akim's sourcequake; I have yet to figure where the relevant passage has been moved :) - Alexandre Duret-Lutz All these patches were sent to and discussed on , so subscribed users were literally drown in technical mails. Eventually, the mailing list was created in May. Year after year, Automake had drifted away from its initial design: construct `Makefile.in' by assembling various `Makefile' fragments. In 1.4, lots of `Makefile' rules are being emitted at various places in the `automake' script itself; this does not help ensuring a consistent treatment of these rules (for instance making sure that user-defined rules override Automake's own rules). One of Akim's goal was moving all these hard-coded rules to separate `Makefile' fragments, so the logic could be centralized in a `Makefile' fragment processor. Another significant contribution of Akim is the interface with the "trace" feature of Autoconf. The way to scan `configure.in' at this time was to read the file and grep the various macro of interest to Automake. Doing so could break in many unexpected ways; automake could miss some definition (for instance `AC_SUBST([$1], [$2])' where the arguments are known only when M4 is run), or conversely it could detect some macro that was not expanded (because it is called conditionally). In the CVS version of Autoconf, Akim had implemented the `--trace' option, which provides accurate information about where macros are actually called and with what arguments. Akim will equip Automake with a second `configure.in' scanner that uses this `--trace' interface. Since it was not sensible to drop the Autoconf 2.13 compatibility yet, this experimental scanner was only used when an environment variable was set, the traditional grep-scanner being still the default. 2001-04-25 Gary V. Vaughan releases Libtool 1.4 It has been more than two years since Automake 1.4, CVS Automake has suffered lot's of heavy changes and still is not ready for release. Libtool 1.4 had to be distributed with a patch against Automake 1.4. 2001-05-08 Automake 1.4-p1 2001-05-24 Automake 1.4-p2 Gary V. Vaughan, the principal Libtool maintainer, makes a "patch release" of Automake: The main purpose of this release is to have a stable automake which is compatible with the latest stable libtool. The release also contains obvious fixes for bugs in Automake 1.4, some of which were reported almost monthly. 2001-05-21 Akim Demaille releases Autoconf 2.50 2001-06-07 Automake 1.4-p3 2001-06-10 Automake 1.4-p4 2001-07-15 Automake 1.4-p5 Gary continues his patch-release series. These also add support for some new Autoconf 2.50 idioms. Essentially, Autoconf now advocates `configure.ac' over `configure.in', and it introduces a new syntax for `AC_OUTPUT'ing files. 2001-08-23 Automake 1.5 A major and long-awaited release, that comes more than two years after 1.4. It brings many changes, among which: * The new dependency tracking scheme that uses `depcomp'. Aside from the improvement on the dependency tracking itself (*note Dependency Tracking Evolution::), this also streamlines the use of automake generated `Makefile.in's as the `Makefile.in's used during development are now the same as those used in distributions. Before that the `Makefile.in's generated for maintainers required GNU `make' and GCC, they were different from the portable `Makefile' generated for distribution; this was causing some confusion. * Support for per-target compilation flags. * Support for reference to files in subdirectories in most `Makefile.am' variables. * Introduction of the `dist_', `nodist_', and `nobase_' prefixes. * Perl 4 support is finally dropped. 1.5 did broke several packages that worked with 1.4. Enough so that Linux distributions could not easily install the new Automake version without breaking many of the packages for which they had to run `automake'. Some of these breakages were effectively bugs that would eventually be fixed in the next release. However, a lot of damage was caused by some changes made deliberately to render Automake stricter on some setup we did consider bogus. For instance, `make distcheck' was improved to check that `make uninstall' did remove all the files `make install' installed, that `make distclean' did not omit some file, and that a VPATH build would work even if the source directory was read-only. Similarly, Automake now rejects multiple definitions of the same variable (because that would mix very badly with conditionals), and `+=' assignments with no previous definition. Because these changes all occurred suddenly after 1.4 had been established for more than two years, it hurt users. To make matter worse, meanwhile Autoconf (now at version 2.52) was facing similar troubles, for similar reasons. 2002-03-05 Automake 1.6 This release introduced versioned installation (*note API versioning::). This was mainly pushed by Havoc Pennington, taking the GNOME source tree as motive: due to incompatibilities between the autotools it's impossible for the GNOME packages to switch to Autoconf 2.53 and Automake 1.5 all at once, so they are currently stuck with Autoconf 2.13 and Automake 1.4. The idea was to call this version `automake-1.6', call all its bug-fix versions identically, and switch to `automake-1.7' for the next release that adds new features or changes some rules. This scheme implies maintaining a bug-fix branch in addition to the development trunk, which means more work from the maintainer, but providing regular bug-fix releases proved to be really worthwhile. Like 1.5, 1.6 also introduced a bunch of incompatibilities, meant or not. Perhaps the more annoying was the dependence on the newly released Autoconf 2.53. Autoconf seemed to have stabilized enough since its explosive 2.50 release, and included changes required to fix some bugs in Automake. In order to upgrade to Automake 1.6, people now had to upgrade Autoconf too; for some packages it was no picnic. While versioned installation helped people to upgrade, it also unfortunately allowed people not to upgrade. At the time of writing, some Linux distributions are shipping packages for Automake 1.4, 1.5, 1.6, 1.7, 1.8, and 1.9. Most of these still install 1.4 by default. Some distribution also call 1.4 the "stable" version, and present "1.9" as the development version; this does not really makes sense since 1.9 is way more solid than 1.4. All this does not help the newcomer. 2002-04-11 Automake 1.6.1 1.6, and the upcoming 1.4-p6 release were the last release by Tom. This one and those following will be handled by Alexandre Duret-Lutz. Tom is still around, and will be there until about 1.7, but his interest into Automake is drifting away towards projects like `gcj'. Alexandre has been using Automake since 2000, and started to contribute mostly on Akim's incitement (Akim and Alexandre have been working in the same room from 1999 to 2002). In 2001 and 2002 he had a lot of free time to enjoy hacking Automake. 2002-06-14 Automake 1.6.2 2002-07-28 Automake 1.6.3 2002-07-28 Automake 1.4-p6 Two releases on the same day. 1.6.3 is a bug-fix release. Tom Tromey backported the versioned installation mechanism on the 1.4 branch, so that Automake 1.6.x and Automake 1.4-p6 could be installed side by side. Another request from the GNOME folks. 2002-09-25 Automake 1.7 This release switches to the new `configure.ac' scanner Akim was experimenting in 1.5. 2002-10-16 Automake 1.7.1 2002-12-06 Automake 1.7.2 2003-02-20 Automake 1.7.3 2003-04-23 Automake 1.7.4 2003-05-18 Automake 1.7.5 2003-07-10 Automake 1.7.6 2003-09-07 Automake 1.7.7 2003-10-07 Automake 1.7.8 Many bug-fix releases. 1.7 lasted because the development version (upcoming 1.8) was suffering some major internal revamping. 2003-10-26 Automake on screen Episode 49, `Repercussions', in the third season of the `Alias' TV show is first aired. Marshall, one of the character, is working on a computer virus that he has to modify before it gets into the wrong hands or something like that. The screenshots you see do not show any program code, they show a `Makefile.in' `generated by automake'... 2003-11-09 Automake 1.7.9 2003-12-10 Automake 1.8 The most striking update is probably that of `aclocal'. `aclocal' now uses `m4_include' in the produced `aclocal.m4' when the included macros are already distributed with the package (an idiom used in many packages), which reduces code duplication. Many people liked that, but in fact this change was really introduced to fix a bug in rebuild rules: `Makefile.in' must be rebuilt whenever a dependency of `configure' changes, but all the `m4' files included in `aclocal.m4' where unknown from `automake'. Now `automake' can just trace the `m4_include's to discover the dependencies. `aclocal' also starts using the `--trace' Autoconf option in order to discover used macros more accurately. This will turn out to be very tricky (later releases will improve this) as people had devised many ways to cope with the limitation of previous `aclocal' versions, notably using handwritten `m4_include's: `aclocal' must make sure not to redefine a rule that is already included by such statement. Automake also has seen its guts rewritten. Although this rewriting took a lot of efforts, it is only apparent to the users in that some constructions previously disallowed by the implementation now work nicely. Conditionals, Locations, Variable and Rule definitions, Options: these items on which Automake works have been rewritten as separate Perl modules, and documented. 2004-01-11 Automake 1.8.1 2004-01-12 Automake 1.8.2 2004-03-07 Automake 1.8.3 2004-04-25 Automake 1.8.4 2004-05-16 Automake 1.8.5 2004-07-28 Automake 1.9 This release tries to simplify the compilation rules it outputs to reduce the size of the Makefile. The complaint initially come from the libgcj developers. Their `Makefile.in' generated with Automake 1.4 and custom build rules (1.4 did not support compiled Java) is 250KB. The one generated by 1.8 was over 9MB! 1.9 gets it down to 1.2MB. Aside from this it contains mainly minor changes and bug-fixes. 2004-08-11 Automake 1.9.1 2004-09-19 Automake 1.9.2 Automake has ten years. This chapter of the manual was initially written for this occasion.  File: automake.info, Node: Dependency Tracking Evolution, Next: Releases, Prev: Timeline, Up: History 28.2 Dependency Tracking in Automake ==================================== Over the years Automake has deployed three different dependency tracking methods. Each method, including the current one, has had flaws of various sorts. Here we lay out the different dependency tracking methods, their flaws, and their fixes. We conclude with recommendations for tool writers, and by indicating future directions for dependency tracking work in Automake. 28.2.1 First Take ----------------- Description ........... Our first attempt at automatic dependency tracking was based on the method recommended by GNU `make'. (*note Generating Prerequisites Automatically: (make)Automatic Prerequisites.) This version worked by precomputing dependencies ahead of time. For each source file, it had a special `.P' file that held the dependencies. There was a rule to generate a `.P' file by invoking the compiler appropriately. All such `.P' files were included by the `Makefile', thus implicitly becoming dependencies of `Makefile'. Bugs .... This approach had several critical bugs. * The code to generate the `.P' file relied on `gcc'. (A limitation, not technically a bug.) * The dependency tracking mechanism itself relied on GNU `make'. (A limitation, not technically a bug.) * Because each `.P' file was a dependency of `Makefile', this meant that dependency tracking was done eagerly by `make'. For instance, `make clean' would cause all the dependency files to be updated, and then immediately removed. This eagerness also caused problems with some configurations; if a certain source file could not be compiled on a given architecture for some reason, dependency tracking would fail, aborting the entire build. * As dependency tracking was done as a pre-pass, compile times were doubled-the compiler had to be run twice per source file. * `make dist' re-ran `automake' to generate a `Makefile' that did not have automatic dependency tracking (and that was thus portable to any version of `make'). In order to do this portably, Automake had to scan the dependency files and remove any reference that was to a source file not in the distribution. This process was error-prone. Also, if `make dist' was run in an environment where some object file had a dependency on a source file that was only conditionally created, Automake would generate a `Makefile' that referred to a file that might not appear in the end user's build. A special, hacky mechanism was required to work around this. Historical Note ............... The code generated by Automake is often inspired by the `Makefile' style of a particular author. In the case of the first implementation of dependency tracking, I believe the impetus and inspiration was Jim Meyering. (I could be mistaken. If you know otherwise feel free to correct me.) 28.2.2 Dependencies As Side Effects ----------------------------------- Description ........... The next refinement of Automake's automatic dependency tracking scheme was to implement dependencies as side effects of the compilation. This was aimed at solving the most commonly reported problems with the first approach. In particular we were most concerned with eliminating the weird rebuilding effect associated with make clean. In this approach, the `.P' files were included using the `-include' command, which let us create these files lazily. This avoided the `make clean' problem. We only computed dependencies when a file was actually compiled. This avoided the performance penalty associated with scanning each file twice. It also let us avoid the other problems associated with the first, eager, implementation. For instance, dependencies would never be generated for a source file that was not compilable on a given architecture (because it in fact would never be compiled). Bugs .... * This approach also relied on the existence of `gcc' and GNU `make'. (A limitation, not technically a bug.) * Dependency tracking was still done by the developer, so the problems from the first implementation relating to massaging of dependencies by `make dist' were still in effect. * This implementation suffered from the "deleted header file" problem. Suppose a lazily-created `.P' file includes a dependency on a given header file, like this: maude.o: maude.c something.h Now suppose that the developer removes `something.h' and updates `maude.c' so that this include is no longer needed. If he runs `make', he will get an error because there is no way to create `something.h'. We fixed this problem in a later release by further massaging the output of `gcc' to include a dummy dependency for each header file. 28.2.3 Dependencies for the User -------------------------------- Description ........... The bugs associated with `make dist', over time, became a real problem. Packages using Automake were being built on a large number of platforms, and were becoming increasingly complex. Broken dependencies were distributed in "portable" `Makefile.in's, leading to user complaints. Also, the requirement for `gcc' and GNU `make' was a constant source of bug reports. The next implementation of dependency tracking aimed to remove these problems. We realized that the only truly reliable way to automatically track dependencies was to do it when the package itself was built. This meant discovering a method portable to any version of make and any compiler. Also, we wanted to preserve what we saw as the best point of the second implementation: dependency computation as a side effect of compilation. In the end we found that most modern make implementations support some form of include directive. Also, we wrote a wrapper script that let us abstract away differences between dependency tracking methods for compilers. For instance, some compilers cannot generate dependencies as a side effect of compilation. In this case we simply have the script run the compiler twice. Currently our wrapper script (`depcomp') knows about twelve different compilers (including a "compiler" that simply invokes `makedepend' and then the real compiler, which is assumed to be a standard Unix-like C compiler with no way to do dependency tracking). Bugs .... * Running a wrapper script for each compilation slows down the build. * Many users don't really care about precise dependencies. * This implementation, like every other automatic dependency tracking scheme in common use today (indeed, every one we've ever heard of), suffers from the "duplicated new header" bug. This bug occurs because dependency tracking tools, such as the compiler, only generate dependencies on the successful opening of a file, and not on every probe. Suppose for instance that the compiler searches three directories for a given header, and that the header is found in the third directory. If the programmer erroneously adds a header file with the same name to the first directory, then a clean rebuild from scratch could fail (suppose the new header file is buggy), whereas an incremental rebuild will succeed. What has happened here is that people have a misunderstanding of what a dependency is. Tool writers think a dependency encodes information about which files were read by the compiler. However, a dependency must actually encode information about what the compiler tried to do. This problem is not serious in practice. Programmers typically do not use the same name for a header file twice in a given project. (At least, not in C or C++. This problem may be more troublesome in Java.) This problem is easy to fix, by modifying dependency generators to record every probe, instead of every successful open. * Since automake generates dependencies as a side effect of compilation, there is a bootstrapping problem when header files are generated by running a program. The problem is that, the first time the build is done, there is no way by default to know that the headers are required, so make might try to run a compilation for which the headers have not yet been built. This was also a problem in the previous dependency tracking implementation. The current fix is to use `BUILT_SOURCES' to list built headers (*note Sources::). This causes them to be built before any other other build rules are run. This is unsatisfactory as a general solution, however in practice it seems sufficient for most actual programs. This code is used since Automake 1.5. In GCC 3.0, we managed to convince the maintainers to add special command-line options to help Automake more efficiently do its job. We hoped this would let us avoid the use of a wrapper script when Automake's automatic dependency tracking was used with `gcc'. Unfortunately, this code doesn't quite do what we want. In particular, it removes the dependency file if the compilation fails; we'd prefer that it instead only touch the file in any way if the compilation succeeds. Nevertheless, since Automake 1.7, when a recent `gcc' is detected at `configure' time, we inline the dependency-generation code and do not use the `depcomp' wrapper script. This makes compilations faster for those using this compiler (probably our primary user base). The counterpart is that because we have to encode two compilation rules in `Makefile' (with or without `depcomp'), the produced `Makefile's are larger. 28.2.4 Techniques for Computing Dependencies -------------------------------------------- There are actually several ways for a build tool like Automake to cause tools to generate dependencies. `makedepend' This was a commonly-used method in the past. The idea is to run a special program over the source and have it generate dependency information. Traditional implementations of `makedepend' are not completely precise; ordinarily they were conservative and discovered too many dependencies. The tool An obvious way to generate dependencies is to simply write the tool so that it can generate the information needed by the build tool. This is also the most portable method. Many compilers have an option to generate dependencies. Unfortunately, not all tools provide such an option. The file system It is possible to write a special file system that tracks opens, reads, writes, etc, and then feed this information back to the build tool. `clearmake' does this. This is a very powerful technique, as it doesn't require cooperation from the tool. Unfortunately it is also very difficult to implement and also not practical in the general case. `LD_PRELOAD' Rather than use the file system, one could write a special library to intercept `open' and other syscalls. This technique is also quite powerful, but unfortunately it is not portable enough for use in `automake'. 28.2.5 Recommendations for Tool Writers --------------------------------------- We think that every compilation tool ought to be able to generate dependencies as a side effect of compilation. Furthermore, at least while `make'-based tools are nearly universally in use (at least in the free software community), the tool itself should generate dummy dependencies for header files, to avoid the deleted header file bug. Finally, the tool should generate a dependency for each probe, instead of each successful file open, in order to avoid the duplicated new header bug. 28.2.6 Future Directions for Automake's Dependency Tracking ----------------------------------------------------------- Currently, only languages and compilers understood by Automake can have dependency tracking enabled. We would like to see if it is practical (and worthwhile) to let this support be extended by the user to languages unknown to Automake.  File: automake.info, Node: Releases, Prev: Dependency Tracking Evolution, Up: History 28.3 Release Statistics ======================= The following table (inspired by `perlhist(1)') quantifies the evolution of Automake using these metrics: Date, Rel The date and version of the release. am The number of lines of the `automake' script. acl The number of lines of the `aclocal' script. pm The number of lines of the `Perl' supporting modules. `*.am' The number of lines of the `Makefile' fragments. The number in parenthesis is the number of files. m4 The number of lines (and files) of Autoconf macros. doc The number of pages of the documentation (the Postscript version). t The number of test cases in the test suite. Date Rel am acl pm `*.am' m4 doc t ------------------------------------------------------------------------------- 1994-09-19 CVS 141 299 (24) 1994-11-05 CVS 208 332 (28) 1995-11-23 0.20 533 458 (35) 9 1995-11-26 0.21 613 480 (36) 11 1995-11-28 0.22 1116 539 (38) 12 1995-11-29 0.23 1240 541 (38) 12 1995-12-08 0.24 1462 504 (33) 14 1995-12-10 0.25 1513 511 (37) 15 1996-01-03 0.26 1706 438 (36) 16 1996-01-03 0.27 1706 438 (36) 16 1996-01-13 0.28 1964 934 (33) 16 1996-02-07 0.29 2299 936 (33) 17 1996-02-24 0.30 2544 919 (32) 85 (1) 20 9 1996-03-11 0.31 2877 919 (32) 85 (1) 29 17 1996-04-27 0.32 3058 921 (31) 85 (1) 30 26 1996-05-18 0.33 3110 926 (31) 105 (1) 30 35 1996-05-28 1.0 3134 973 (32) 105 (1) 30 38 1997-06-22 1.2 6089 385 1294 (36) 592 (20) 37 126 1998-04-05 1.3 6415 422 1470 (39) 741 (23) 39 156 1999-01-14 1.4 7240 426 1591 (40) 734 (20) 51 197 2001-05-08 1.4-p1 7251 426 1591 (40) 734 (20) 51 197 2001-05-24 1.4-p2 7268 439 1591 (40) 734 (20) 49 197 2001-06-07 1.4-p3 7312 439 1591 (40) 734 (20) 49 197 2001-06-10 1.4-p4 7321 439 1591 (40) 734 (20) 49 198 2001-07-15 1.4-p5 7228 426 1596 (40) 734 (20) 51 198 2001-08-23 1.5 8016 475 600 2654 (39) 1166 (29) 63 327 2002-03-05 1.6 8465 475 1136 2732 (39) 1603 (27) 66 365 2002-04-11 1.6.1 8544 475 1136 2741 (39) 1603 (27) 66 372 2002-06-14 1.6.2 8575 475 1136 2800 (39) 1609 (27) 67 386 2002-07-28 1.6.3 8600 475 1153 2809 (39) 1609 (27) 67 391 2002-07-28 1.4-p6 7332 455 1596 (40) 735 (20) 49 197 2002-09-25 1.7 9189 471 1790 2965 (39) 1606 (28) 73 430 2002-10-16 1.7.1 9229 475 1790 2977 (39) 1606 (28) 73 437 2002-12-06 1.7.2 9334 475 1790 2988 (39) 1606 (28) 77 445 2003-02-20 1.7.3 9389 475 1790 3023 (39) 1651 (29) 84 448 2003-04-23 1.7.4 9429 475 1790 3031 (39) 1644 (29) 85 458 2003-05-18 1.7.5 9429 475 1790 3033 (39) 1645 (29) 85 459 2003-07-10 1.7.6 9442 475 1790 3033 (39) 1660 (29) 85 461 2003-09-07 1.7.7 9443 475 1790 3041 (39) 1660 (29) 90 467 2003-10-07 1.7.8 9444 475 1790 3041 (39) 1660 (29) 90 468 2003-11-09 1.7.9 9444 475 1790 3048 (39) 1660 (29) 90 468 2003-12-10 1.8 7171 585 7730 3236 (39) 1666 (31) 104 521 2004-01-11 1.8.1 7217 663 7726 3287 (39) 1686 (31) 104 525 2004-01-12 1.8.2 7217 663 7726 3288 (39) 1686 (31) 104 526 2004-03-07 1.8.3 7214 686 7735 3303 (39) 1695 (31) 111 530 2004-04-25 1.8.4 7214 686 7736 3310 (39) 1701 (31) 112 531 2004-05-16 1.8.5 7240 686 7736 3299 (39) 1701 (31) 112 533 2004-07-28 1.9 7508 715 7794 3352 (40) 1812 (32) 115 551 2004-08-11 1.9.1 7512 715 7794 3354 (40) 1812 (32) 115 552 2004-09-19 1.9.2 7512 715 7794 3354 (40) 1812 (32) 132 554 2004-11-01 1.9.3 7507 718 7804 3354 (40) 1812 (32) 134 556 2004-12-18 1.9.4 7508 718 7856 3361 (40) 1811 (32) 140 560 2005-02-13 1.9.5 7523 719 7859 3373 (40) 1453 (32) 142 562 2005-07-10 1.9.6 7539 699 7867 3400 (40) 1453 (32) 144 570 2006-10-15 1.10 7859 1072 8024 3512 (40) 1496 (34) 172 604  File: automake.info, Node: Copying This Manual, Next: Indices, Prev: History, Up: Top Appendix A Copying This Manual ****************************** * Menu: * GNU Free Documentation License:: License for copying this manual  File: automake.info, Node: GNU Free Documentation License, Up: Copying This Manual A.1 GNU Free Documentation License ================================== Version 1.2, November 2002 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. 2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. 3. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. O. Preserve any Warranty Disclaimers. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. 5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements." 6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. 7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate. 8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title. 9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See `http://www.gnu.org/copyleft/'. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. A.1.1 ADDENDUM: How to use this License for your documents ---------------------------------------------------------- To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: Copyright (C) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''. If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this: with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.  File: automake.info, Node: Indices, Prev: Copying This Manual, Up: Top Appendix B Indices ****************** * Menu: * Macro Index:: Index of Autoconf macros * Variable Index:: Index of Makefile variables * General Index:: General index  File: automake.info, Node: Macro Index, Next: Variable Index, Up: Indices B.1 Macro Index =============== [index] * Menu: * _AM_DEPENDENCIES: Private macros. (line 12) * AC_CANONICAL_BUILD: Optional. (line 11) * AC_CANONICAL_HOST: Optional. (line 12) * AC_CANONICAL_TARGET: Optional. (line 13) * AC_CONFIG_AUX_DIR <1>: Subpackages. (line 6) * AC_CONFIG_AUX_DIR: Optional. (line 19) * AC_CONFIG_FILES: Requirements. (line 15) * AC_CONFIG_HEADERS: Optional. (line 46) * AC_CONFIG_LIBOBJ_DIR <1>: LIBOBJS. (line 48) * AC_CONFIG_LIBOBJ_DIR: Optional. (line 41) * AC_CONFIG_LINKS: Optional. (line 55) * AC_CONFIG_SUBDIRS: Subpackages. (line 6) * AC_DEFUN: Extending aclocal. (line 33) * AC_F77_LIBRARY_LDFLAGS: Optional. (line 98) * AC_INIT: Public macros. (line 25) * AC_LIBOBJ <1>: LIBOBJS. (line 11) * AC_LIBOBJ <2>: LTLIBOBJS. (line 6) * AC_LIBOBJ: Optional. (line 65) * AC_LIBSOURCE <1>: LIBOBJS. (line 17) * AC_LIBSOURCE: Optional. (line 66) * AC_LIBSOURCES: Optional. (line 67) * AC_OUTPUT: Requirements. (line 15) * AC_PREREQ: Extending aclocal. (line 33) * AC_PROG_CC_C_O: Public macros. (line 80) * AC_PROG_CXX: Optional. (line 85) * AC_PROG_F77: Optional. (line 93) * AC_PROG_FC: Optional. (line 104) * AC_PROG_LEX <1>: Public macros. (line 86) * AC_PROG_LEX: Optional. (line 119) * AC_PROG_LIBTOOL: Optional. (line 109) * AC_PROG_OBJC: Optional. (line 89) * AC_PROG_RANLIB: Optional. (line 81) * AC_PROG_YACC: Optional. (line 113) * AC_REQUIRE_AUX_FILE: Optional. (line 123) * AC_SUBST: Optional. (line 131) * AM_C_PROTOTYPES <1>: ANSI. (line 34) * AM_C_PROTOTYPES <2>: Obsolete macros. (line 13) * AM_C_PROTOTYPES: Optional. (line 142) * AM_CONDITIONAL: Conditionals. (line 11) * AM_CONFIG_HEADER: Obsolete macros. (line 20) * AM_DEP_TRACK: Private macros. (line 14) * AM_ENABLE_MULTILIB: Public macros. (line 7) * AM_GNU_GETTEXT: Optional. (line 146) * AM_GNU_GETTEXT_INTL_SUBDIR: Optional. (line 152) * AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL: Obsolete macros. (line 25) * AM_INIT_AUTOMAKE <1>: Public macros. (line 16) * AM_INIT_AUTOMAKE: Requirements. (line 6) * AM_MAINTAINER_MODE <1>: maintainer-mode. (line 36) * AM_MAINTAINER_MODE <2>: Rebuilding. (line 9) * AM_MAINTAINER_MODE: Optional. (line 157) * AM_MAKE_INCLUDE: Private macros. (line 20) * AM_OUTPUT_DEPENDENCY_COMMANDS: Private macros. (line 15) * AM_PATH_LISPDIR: Public macros. (line 60) * AM_PATH_PYTHON: Python. (line 29) * AM_PROG_AS: Public macros. (line 75) * AM_PROG_CC_C_O: Public macros. (line 80) * AM_PROG_GCJ: Public macros. (line 91) * AM_PROG_INSTALL_STRIP: Private macros. (line 25) * AM_PROG_LEX: Public macros. (line 86) * AM_PROG_MKDIR_P: Obsolete macros. (line 31) * AM_PROG_UPC: Public macros. (line 96) * AM_SANITY_CHECK: Private macros. (line 30) * AM_SET_DEPDIR: Private macros. (line 13) * AM_SYS_POSIX_TERMIOS: Obsolete macros. (line 53) * AM_WITH_DMALLOC: Public macros. (line 102) * AM_WITH_REGEX: Public macros. (line 107) * m4_include <1>: Dist. (line 17) * m4_include: Optional. (line 165)  File: automake.info, Node: Variable Index, Next: General Index, Prev: Macro Index, Up: Indices B.2 Variable Index ================== [index] * Menu: * _DATA: Data. (line 6) * _HEADERS: Headers. (line 6) * _LIBRARIES: A Library. (line 6) * _LISP: Emacs Lisp. (line 6) * _LTLIBRARIES: Libtool Libraries. (line 6) * _MANS: Man pages. (line 6) * _PROGRAMS <1>: Program Sources. (line 6) * _PROGRAMS: Uniform. (line 11) * _PYTHON: Python. (line 6) * _SCRIPTS: Scripts. (line 6) * _SOURCES <1>: Default _SOURCES. (line 6) * _SOURCES: Program Sources. (line 32) * _TEXINFOS: Texinfo. (line 6) * ACLOCAL_AMFLAGS <1>: Rebuilding. (line 12) * ACLOCAL_AMFLAGS: Local Macros. (line 19) * ALLOCA <1>: LIBOBJS. (line 6) * ALLOCA: LTLIBOBJS. (line 6) * AM_CCASFLAGS: Assembly Support. (line 9) * AM_CFLAGS: Program variables. (line 36) * AM_CPPFLAGS <1>: Assembly Support. (line 9) * AM_CPPFLAGS: Program variables. (line 15) * AM_CXXFLAGS: C++ Support. (line 22) * AM_ETAGSFLAGS: Tags. (line 25) * AM_FCFLAGS: Fortran 9x Support. (line 22) * AM_FFLAGS: Fortran 77 Support. (line 22) * AM_GCJFLAGS: Java Support. (line 24) * AM_INSTALLCHECK_STD_OPTIONS_EXEMPT: Options. (line 120) * AM_JAVACFLAGS: Java. (line 36) * AM_LDFLAGS <1>: Program variables. (line 46) * AM_LDFLAGS: Linking. (line 10) * AM_LFLAGS: Yacc and Lex. (line 56) * AM_LIBTOOLFLAGS: Libtool Flags. (line 6) * AM_MAKEFLAGS: Subdirectories. (line 29) * AM_MAKEINFOFLAGS: Texinfo. (line 101) * AM_MAKEINFOHTMLFLAGS: Texinfo. (line 102) * AM_OBJCFLAGS: Objective C Support. (line 22) * AM_RFLAGS: Fortran 77 Support. (line 28) * AM_RUNTESTFLAGS: Tests. (line 75) * AM_UPCFLAGS: Unified Parallel C Support. (line 21) * AM_YFLAGS: Yacc and Lex. (line 33) * ANSI2KNR: Obsolete macros. (line 13) * AUTOCONF: Invoking Automake. (line 28) * AUTOM4TE: Invoking aclocal. (line 45) * AUTOMAKE_OPTIONS <1>: Options. (line 11) * AUTOMAKE_OPTIONS <2>: Dependencies. (line 34) * AUTOMAKE_OPTIONS <3>: ANSI. (line 21) * AUTOMAKE_OPTIONS: Public macros. (line 19) * bin_PROGRAMS: Program Sources. (line 6) * bin_SCRIPTS: Scripts. (line 18) * build_triplet: Optional. (line 14) * BUILT_SOURCES: Sources. (line 27) * CC: Program variables. (line 11) * CCAS <1>: Assembly Support. (line 9) * CCAS: Public macros. (line 75) * CCASFLAGS <1>: Assembly Support. (line 9) * CCASFLAGS: Public macros. (line 75) * CFLAGS: Program variables. (line 11) * check_: Uniform. (line 74) * check_LTLIBRARIES: Libtool Convenience Libraries. (line 6) * check_PROGRAMS <1>: Default _SOURCES. (line 29) * check_PROGRAMS: Program Sources. (line 6) * check_SCRIPTS: Scripts. (line 18) * CLASSPATH_ENV: Java. (line 45) * CLEANFILES: Clean. (line 13) * COMPILE: Program variables. (line 42) * CONFIG_STATUS_DEPENDENCIES: Rebuilding. (line 19) * CONFIGURE_DEPENDENCIES: Rebuilding. (line 19) * CPPFLAGS <1>: Assembly Support. (line 9) * CPPFLAGS: Program variables. (line 11) * CXX: C++ Support. (line 16) * CXXCOMPILE: C++ Support. (line 25) * CXXFLAGS: C++ Support. (line 19) * CXXLINK <1>: How the Linker is Chosen. (line 12) * CXXLINK: C++ Support. (line 29) * DATA <1>: Data. (line 7) * DATA: Uniform. (line 79) * data_DATA: Data. (line 9) * DEFS: Program variables. (line 11) * DEJATOOL: Tests. (line 70) * DESTDIR <1>: Install. (line 79) * DESTDIR: DESTDIR. (line 6) * dist_ <1>: Dist. (line 53) * dist_: Alternative. (line 30) * dist_lisp_LISP: Emacs Lisp. (line 11) * dist_noinst_LISP: Emacs Lisp. (line 11) * DIST_SUBDIRS <1>: Dist. (line 41) * DIST_SUBDIRS: Conditional Subdirectories. (line 84) * DISTCHECK_CONFIGURE_FLAGS: Dist. (line 117) * distcleancheck_listfiles <1>: distcleancheck. (line 115) * distcleancheck_listfiles: Dist. (line 111) * DISTCLEANFILES <1>: Dist. (line 133) * DISTCLEANFILES: Clean. (line 13) * distdir <1>: Third-Party Makefiles. (line 25) * distdir: Dist. (line 89) * distuninstallcheck_listfiles: Dist. (line 111) * DVIPS: Texinfo. (line 127) * EMACS: Public macros. (line 60) * ETAGS_ARGS: Tags. (line 25) * ETAGSFLAGS: Tags. (line 25) * EXPECT: Tests. (line 70) * EXTRA_DIST: Dist. (line 30) * EXTRA_maude_SOURCES: Program and Library Variables. (line 53) * EXTRA_PROGRAMS: Conditional Programs. (line 15) * F77: Fortran 77 Support. (line 16) * F77COMPILE: Fortran 77 Support. (line 31) * F77LINK: How the Linker is Chosen. (line 14) * FC: Fortran 9x Support. (line 16) * FCCOMPILE: Fortran 9x Support. (line 25) * FCFLAGS: Fortran 9x Support. (line 19) * FCLINK <1>: Fortran 9x Support. (line 29) * FCLINK: How the Linker is Chosen. (line 16) * FFLAGS: Fortran 77 Support. (line 19) * FLIBS: Mixing Fortran 77 With C and C++. (line 21) * FLINK: Fortran 77 Support. (line 35) * GCJ: Public macros. (line 91) * GCJFLAGS <1>: Java Support. (line 14) * GCJFLAGS: Public macros. (line 91) * GCJLINK: How the Linker is Chosen. (line 10) * GTAGS_ARGS: Tags. (line 49) * GZIP_ENV: Dist. (line 13) * HEADERS: Uniform. (line 79) * host_triplet: Optional. (line 14) * include_HEADERS: Headers. (line 6) * INCLUDES: Program variables. (line 30) * info_TEXINFOS: Texinfo. (line 6) * JAVA: Uniform. (line 79) * JAVAC: Java. (line 29) * JAVACFLAGS: Java. (line 32) * JAVAROOT: Java. (line 41) * LDADD: Linking. (line 10) * LDFLAGS: Program variables. (line 11) * LFLAGS: Yacc and Lex. (line 56) * lib_LIBRARIES: A Library. (line 6) * lib_LTLIBRARIES: Libtool Libraries. (line 6) * libexec_PROGRAMS: Program Sources. (line 6) * libexec_SCRIPTS: Scripts. (line 18) * LIBOBJS <1>: LIBOBJS. (line 6) * LIBOBJS <2>: LTLIBOBJS. (line 6) * LIBOBJS: Optional. (line 68) * LIBRARIES: Uniform. (line 79) * LIBS: Program variables. (line 11) * LIBTOOLFLAGS: Libtool Flags. (line 6) * LINK <1>: How the Linker is Chosen. (line 22) * LINK: Program variables. (line 51) * LISP: Uniform. (line 79) * lisp_LISP: Emacs Lisp. (line 6) * lispdir: Public macros. (line 60) * localstate_DATA: Data. (line 9) * LTALLOCA <1>: LIBOBJS. (line 6) * LTALLOCA: LTLIBOBJS. (line 6) * LTLIBOBJS <1>: LIBOBJS. (line 6) * LTLIBOBJS: LTLIBOBJS. (line 6) * MAINTAINERCLEANFILES: Clean. (line 13) * MAKE: Subdirectories. (line 29) * MAKEINFO: Texinfo. (line 85) * MAKEINFOFLAGS: Texinfo. (line 95) * MAKEINFOHTML: Texinfo. (line 91) * man_MANS: Man pages. (line 6) * MANS: Uniform. (line 79) * maude_AR: Program and Library Variables. (line 68) * maude_CCASFLAGS: Program and Library Variables. (line 160) * maude_CFLAGS: Program and Library Variables. (line 161) * maude_CPPFLAGS: Program and Library Variables. (line 162) * maude_CXXFLAGS: Program and Library Variables. (line 163) * maude_DEPENDENCIES <1>: Program and Library Variables. (line 118) * maude_DEPENDENCIES: Linking. (line 41) * maude_FFLAGS: Program and Library Variables. (line 164) * maude_GCJFLAGS: Program and Library Variables. (line 165) * maude_LDADD <1>: Program and Library Variables. (line 86) * maude_LDADD: Linking. (line 17) * maude_LDFLAGS <1>: Program and Library Variables. (line 106) * maude_LDFLAGS: Linking. (line 37) * maude_LFLAGS: Program and Library Variables. (line 166) * maude_LIBADD <1>: Program and Library Variables. (line 78) * maude_LIBADD: A Library. (line 26) * maude_LIBTOOLFLAGS <1>: Program and Library Variables. (line 111) * maude_LIBTOOLFLAGS: Libtool Flags. (line 6) * maude_LINK: Program and Library Variables. (line 149) * maude_OBJCFLAGS: Program and Library Variables. (line 167) * maude_RFLAGS: Program and Library Variables. (line 168) * maude_SHORTNAME: Program and Library Variables. (line 201) * maude_SOURCES: Program and Library Variables. (line 18) * maude_UPCFLAGS: Program and Library Variables. (line 169) * maude_YFLAGS: Program and Library Variables. (line 170) * mkdir_p: Obsolete macros. (line 31) * MKDIR_P: Obsolete macros. (line 31) * MOSTLYCLEANFILES: Clean. (line 13) * nobase_: Alternative. (line 24) * nodist_ <1>: Dist. (line 53) * nodist_: Alternative. (line 30) * noinst_: Uniform. (line 69) * noinst_HEADERS: Headers. (line 6) * noinst_LIBRARIES: A Library. (line 6) * noinst_LISP: Emacs Lisp. (line 6) * noinst_LTLIBRARIES: Libtool Convenience Libraries. (line 6) * noinst_PROGRAMS: Program Sources. (line 6) * noinst_SCRIPTS: Scripts. (line 18) * OBJC: Objective C Support. (line 16) * OBJCCOMPILE: Objective C Support. (line 25) * OBJCFLAGS: Objective C Support. (line 19) * OBJCLINK <1>: How the Linker is Chosen. (line 18) * OBJCLINK: Objective C Support. (line 29) * oldinclude_HEADERS: Headers. (line 6) * PACKAGE: Dist. (line 9) * pkgdata_DATA: Data. (line 9) * pkgdata_SCRIPTS: Scripts. (line 18) * pkgdatadir: Uniform. (line 19) * pkginclude_HEADERS: Headers. (line 6) * pkgincludedir: Uniform. (line 19) * pkglib_LIBRARIES: A Library. (line 6) * pkglib_LTLIBRARIES: Libtool Libraries. (line 6) * pkglib_PROGRAMS: Program Sources. (line 6) * pkglibdir: Uniform. (line 19) * pkgpyexecdir: Python. (line 99) * pkgpythondir: Python. (line 85) * PROGRAMS: Uniform. (line 17) * pyexecdir: Python. (line 90) * PYTHON <1>: Python. (line 50) * PYTHON: Uniform. (line 79) * PYTHON_EXEC_PREFIX: Python. (line 71) * PYTHON_PLATFORM: Python. (line 76) * PYTHON_PREFIX: Python. (line 66) * PYTHON_VERSION: Python. (line 62) * pythondir: Python. (line 81) * RFLAGS: Fortran 77 Support. (line 25) * RUNTEST: Tests. (line 70) * RUNTESTDEFAULTFLAGS: Tests. (line 65) * RUNTESTFLAGS: Tests. (line 75) * sbin_PROGRAMS: Program Sources. (line 6) * sbin_SCRIPTS: Scripts. (line 18) * SCRIPTS <1>: Scripts. (line 9) * SCRIPTS: Uniform. (line 79) * sharedstate_DATA: Data. (line 9) * SOURCES <1>: Default _SOURCES. (line 6) * SOURCES: Program Sources. (line 33) * SUBDIRS <1>: Dist. (line 41) * SUBDIRS: Subdirectories. (line 8) * SUFFIXES: Suffixes. (line 6) * sysconf_DATA: Data. (line 9) * TAGS_DEPENDENCIES: Tags. (line 35) * target_triplet: Optional. (line 14) * TESTS: Tests. (line 24) * TESTS_ENVIRONMENT: Tests. (line 24) * TEXI2DVI: Texinfo. (line 118) * TEXI2PDF: Texinfo. (line 123) * TEXINFO_TEX: Texinfo. (line 131) * TEXINFOS <1>: Texinfo. (line 59) * TEXINFOS: Uniform. (line 79) * top_distdir <1>: Third-Party Makefiles. (line 25) * top_distdir: Dist. (line 89) * U: Obsolete macros. (line 13) * UPC <1>: Unified Parallel C Support. (line 15) * UPC: Public macros. (line 96) * UPCCOMPILE: Unified Parallel C Support. (line 24) * UPCFLAGS: Unified Parallel C Support. (line 18) * UPCLINK <1>: How the Linker is Chosen. (line 20) * UPCLINK: Unified Parallel C Support. (line 28) * VERSION: Dist. (line 9) * WARNINGS <1>: aclocal options. (line 85) * WARNINGS: Invoking Automake. (line 164) * WITH_DMALLOC: Public macros. (line 102) * WITH_REGEX: Public macros. (line 107) * XFAIL_TESTS: Tests. (line 36) * YACC: Optional. (line 114) * YFLAGS: Yacc and Lex. (line 33)  File: automake.info, Node: General Index, Prev: Variable Index, Up: Indices B.3 General Index ================= [index] * Menu: * ## (special Automake comment): General Operation. (line 54) * #serial syntax: Serials. (line 6) * $(LIBOBJS) and empty libraries: LIBOBJS. (line 69) * +=: General Operation. (line 23) * --acdir: aclocal options. (line 9) * --add-missing: Invoking Automake. (line 41) * --build=BUILD: Cross-Compilation. (line 14) * --copy: Invoking Automake. (line 63) * --cygnus: Invoking Automake. (line 67) * --diff: aclocal options. (line 13) * --disable-dependency-tracking: Dependency Tracking. (line 29) * --dry-run: aclocal options. (line 18) * --enable-debug, example: Conditionals. (line 26) * --enable-dependency-tracking: Dependency Tracking. (line 39) * --enable-maintainer-mode: Optional. (line 158) * --force: aclocal options. (line 39) * --force-missing: Invoking Automake. (line 72) * --foreign: Invoking Automake. (line 78) * --gnits: Invoking Automake. (line 82) * --gnits, complete description: Gnits. (line 21) * --gnu: Invoking Automake. (line 86) * --gnu, complete description: Gnits. (line 6) * --gnu, required files: Gnits. (line 6) * --help <1>: aclocal options. (line 22) * --help: Invoking Automake. (line 90) * --help check: Options. (line 115) * --help=recursive: Nested Packages. (line 30) * --host=HOST: Cross-Compilation. (line 17) * --include-deps: Invoking Automake. (line 98) * --install: aclocal options. (line 29) * --libdir: Invoking Automake. (line 58) * --no-force: Invoking Automake. (line 103) * --output: aclocal options. (line 49) * --output-dir: Invoking Automake. (line 110) * --prefix: Standard Directory Variables. (line 33) * --print-ac-dir: aclocal options. (line 52) * --program-prefix=PREFIX: Renaming. (line 16) * --program-suffix=SUFFIX: Renaming. (line 19) * --program-transform-name=PROGRAM: Renaming. (line 22) * --target=TARGET: Cross-Compilation. (line 56) * --verbose <1>: aclocal options. (line 58) * --verbose: Invoking Automake. (line 117) * --version <1>: aclocal options. (line 61) * --version: Invoking Automake. (line 121) * --version check: Options. (line 115) * --warnings <1>: aclocal options. (line 66) * --warnings: Invoking Automake. (line 126) * --with-dmalloc: Public macros. (line 102) * --with-regex: Public macros. (line 107) * -a: Invoking Automake. (line 41) * -c: Invoking Automake. (line 62) * -f: Invoking Automake. (line 71) * -hook targets: Extending. (line 61) * -I: aclocal options. (line 25) * -i: Invoking Automake. (line 94) * -l and LDADD: Linking. (line 66) * -local targets: Extending. (line 36) * -module, libtool: Libtool Modules. (line 6) * -o: Invoking Automake. (line 110) * -v: Invoking Automake. (line 117) * -W <1>: aclocal options. (line 66) * -W: Invoking Automake. (line 126) * -Wall: amhello Explained. (line 38) * -Werror: amhello Explained. (line 38) * .la suffix, defined: Libtool Concept. (line 6) * _DATA primary, defined: Data. (line 6) * _DEPENDENCIES, defined: Linking. (line 41) * _HEADERS primary, defined: Headers. (line 6) * _JAVA primary, defined: Java. (line 6) * _LDFLAGS, defined: Linking. (line 37) * _LDFLAGS, libtool: Libtool Flags. (line 6) * _LIBADD, libtool: Libtool Flags. (line 6) * _LIBRARIES primary, defined: A Library. (line 6) * _LIBTOOLFLAGS, libtool: Libtool Flags. (line 6) * _LISP primary, defined: Emacs Lisp. (line 6) * _LTLIBRARIES primary, defined: Libtool Libraries. (line 6) * _MANS primary, defined: Man pages. (line 6) * _PROGRAMS primary variable: Uniform. (line 11) * _PYTHON primary, defined: Python. (line 6) * _SCRIPTS primary, defined: Scripts. (line 6) * _SOURCES and header files: Program Sources. (line 39) * _SOURCES primary, defined: Program Sources. (line 32) * _SOURCES, default: Default _SOURCES. (line 6) * _SOURCES, empty: Default _SOURCES. (line 43) * _TEXINFOS primary, defined: Texinfo. (line 6) * AC_SUBST and SUBDIRS: Conditional Subdirectories. (line 95) * acinclude.m4, defined: Complete. (line 23) * aclocal and serial numbers: Serials. (line 6) * aclocal program, introduction: Complete. (line 23) * aclocal search path: Macro search path. (line 6) * aclocal's scheduled death: Future of aclocal. (line 6) * aclocal, extending: Extending aclocal. (line 6) * aclocal, Invoking: Invoking aclocal. (line 6) * aclocal, Options: aclocal options. (line 6) * aclocal.m4, preexisting: Complete. (line 23) * Adding new SUFFIXES: Suffixes. (line 6) * all <1>: Extending. (line 40) * all: Standard Targets. (line 16) * all-local: Extending. (line 40) * ALLOCA, and Libtool: LTLIBOBJS. (line 6) * ALLOCA, example: LIBOBJS. (line 6) * ALLOCA, special handling: LIBOBJS. (line 6) * AM_CCASFLAGS and CCASFLAGS: Flag Variables Ordering. (line 20) * AM_CFLAGS and CFLAGS: Flag Variables Ordering. (line 20) * AM_CONDITIONAL and SUBDIRS: Conditional Subdirectories. (line 65) * AM_CPPFLAGS and CPPFLAGS: Flag Variables Ordering. (line 20) * AM_CXXFLAGS and CXXFLAGS: Flag Variables Ordering. (line 20) * AM_FCFLAGS and FCFLAGS: Flag Variables Ordering. (line 20) * AM_FFLAGS and FFLAGS: Flag Variables Ordering. (line 20) * AM_GCJFLAGS and GCJFLAGS: Flag Variables Ordering. (line 20) * AM_INIT_AUTOMAKE, example use: Complete. (line 11) * AM_LDFLAGS and LDFLAGS: Flag Variables Ordering. (line 20) * AM_LFLAGS and LFLAGS: Flag Variables Ordering. (line 20) * AM_LIBTOOLFLAGS and LIBTOOLFLAGS: Flag Variables Ordering. (line 20) * AM_MAINTAINER_MODE, purpose: maintainer-mode. (line 36) * AM_OBJCFLAGS and OBJCFLAGS: Flag Variables Ordering. (line 20) * AM_RFLAGS and RFLAGS: Flag Variables Ordering. (line 20) * AM_UPCFLAGS and UPCFLAGS: Flag Variables Ordering. (line 20) * AM_YFLAGS and YFLAGS: Flag Variables Ordering. (line 20) * amhello-1.0.tar.gz, creation: Hello World. (line 6) * amhello-1.0.tar.gz, location: Use Cases. (line 6) * amhello-1.0.tar.gz, use cases: Use Cases. (line 6) * ansi2knr <1>: Options. (line 22) * ansi2knr: ANSI. (line 21) * ansi2knr and LIBOBJS: ANSI. (line 56) * ansi2knr and LTLIBOBJS: ANSI. (line 56) * Append operator: General Operation. (line 23) * autogen.sh and autoreconf: Libtool Issues. (line 9) * autom4te: Invoking aclocal. (line 45) * Automake constraints: Introduction. (line 22) * automake options: Invoking Automake. (line 37) * Automake requirements <1>: Requirements. (line 6) * Automake requirements: Introduction. (line 27) * automake, invoking: Invoking Automake. (line 6) * Automake, recursive operation: General Operation. (line 44) * Automatic dependency tracking: Dependencies. (line 11) * Automatic linker selection: How the Linker is Chosen. (line 6) * autoreconf and libtoolize: Libtool Issues. (line 9) * autoreconf, example: Creating amhello. (line 59) * autoscan: amhello Explained. (line 90) * Autotools, introduction: GNU Build System. (line 43) * Autotools, purpose: Why Autotools. (line 6) * autoupdate: Obsolete macros. (line 6) * Auxiliary programs: Auxiliary Programs. (line 6) * Avoiding path stripping: Alternative. (line 24) * Binary package: DESTDIR. (line 22) * bootstrap.sh and autoreconf: Libtool Issues. (line 9) * Bugs, reporting: Introduction. (line 31) * build tree and source tree: VPATH Builds. (line 6) * BUILT_SOURCES, defined: Sources. (line 27) * C++ support: C++ Support. (line 6) * canonicalizing Automake variables: Canonicalization. (line 6) * CCASFLAGS and AM_CCASFLAGS: Flag Variables Ordering. (line 20) * CFLAGS and AM_CFLAGS: Flag Variables Ordering. (line 20) * cfortran: Mixing Fortran 77 With C and C++. (line 6) * check <1>: Extending. (line 40) * check <2>: Tests. (line 6) * check: Standard Targets. (line 37) * check-local: Extending. (line 40) * check-news: Options. (line 29) * check_ primary prefix, definition: Uniform. (line 74) * check_PROGRAMS example: Default _SOURCES. (line 29) * clean <1>: Extending. (line 40) * clean: Standard Targets. (line 31) * clean-local <1>: Extending. (line 40) * clean-local: Clean. (line 15) * Comment, special to Automake: General Operation. (line 54) * Compile Flag Variables: Flag Variables Ordering. (line 20) * Complete example: Complete. (line 6) * Conditional example, --enable-debug: Conditionals. (line 26) * conditional libtool libraries: Conditional Libtool Libraries. (line 6) * Conditional programs: Conditional Programs. (line 6) * Conditional subdirectories: Conditional Subdirectories. (line 6) * Conditional SUBDIRS: Conditional Subdirectories. (line 6) * Conditionals: Conditionals. (line 6) * config.guess: Invoking Automake. (line 39) * config.site example: config.site. (line 6) * configuration variables, overriding: Standard Configuration Variables. (line 6) * Configuration, basics: Basic Installation. (line 6) * configure.ac, scanning: configure. (line 6) * conflicting definitions: Extending. (line 14) * Constraints of Automake: Introduction. (line 22) * convenience libraries, libtool: Libtool Convenience Libraries. (line 6) * copying semantics: Extending. (line 10) * cpio example: Uniform. (line 36) * CPPFLAGS and AM_CPPFLAGS: Flag Variables Ordering. (line 20) * cross-compilation: Cross-Compilation. (line 6) * cross-compilation example: Cross-Compilation. (line 26) * CVS and generated files: CVS. (line 49) * CVS and third-party files: CVS. (line 140) * CVS and timestamps: CVS. (line 28) * cvs-dist: General Operation. (line 12) * cvs-dist, non-standard example: General Operation. (line 12) * CXXFLAGS and AM_CXXFLAGS: Flag Variables Ordering. (line 20) * cygnus: Options. (line 17) * cygnus strictness: Cygnus. (line 6) * DATA primary, defined: Data. (line 6) * de-ANSI-fication, defined: ANSI. (line 6) * debug build, example: VPATH Builds. (line 47) * default _SOURCES: Default _SOURCES. (line 6) * default source, Libtool modules example: Default _SOURCES. (line 37) * definitions, conflicts: Extending. (line 14) * dejagnu <1>: Options. (line 33) * dejagnu: Tests. (line 70) * depcomp: Dependencies. (line 22) * dependencies and distributed files: distcleancheck. (line 6) * Dependency tracking <1>: Dependencies. (line 11) * Dependency tracking: Dependency Tracking. (line 6) * Dependency tracking, disabling: Dependencies. (line 37) * directory variables: Standard Directory Variables. (line 6) * dirlist: Macro search path. (line 62) * Disabling dependency tracking: Dependencies. (line 37) * dist <1>: Dist. (line 9) * dist: Standard Targets. (line 43) * dist-bzip2 <1>: Options. (line 36) * dist-bzip2: Dist. (line 192) * dist-gzip: Dist. (line 195) * dist-hook <1>: Extending. (line 64) * dist-hook: Dist. (line 71) * dist-shar <1>: Options. (line 39) * dist-shar: Dist. (line 198) * dist-tarZ <1>: Options. (line 45) * dist-tarZ: Dist. (line 204) * dist-zip <1>: Options. (line 42) * dist-zip: Dist. (line 201) * dist_ and nobase_: Alternative. (line 30) * DIST_SUBDIRS, explained: Conditional Subdirectories. (line 34) * distcheck <1>: Dist. (line 111) * distcheck: Creating amhello. (line 99) * distcheck better than dist: Preparing Distributions. (line 10) * distcheck example: Creating amhello. (line 99) * distcheck-hook: Dist. (line 122) * distclean <1>: distcleancheck. (line 6) * distclean <2>: Extending. (line 40) * distclean: Standard Targets. (line 34) * distclean, diagnostic: distcleancheck. (line 6) * distclean-local <1>: Extending. (line 40) * distclean-local: Clean. (line 15) * distcleancheck <1>: distcleancheck. (line 6) * distcleancheck: Dist. (line 133) * distdir: Third-Party Makefiles. (line 25) * Distributions, preparation: Preparing Distributions. (line 6) * dmalloc, support for: Public macros. (line 102) * dvi <1>: Extending. (line 40) * dvi: Texinfo. (line 19) * DVI output using Texinfo: Texinfo. (line 6) * dvi-local: Extending. (line 40) * E-mail, bug reports: Introduction. (line 31) * EDITION Texinfo flag: Texinfo. (line 29) * else: Conditionals. (line 41) * empty _SOURCES: Default _SOURCES. (line 43) * Empty libraries: A Library. (line 46) * Empty libraries and $(LIBOBJS): LIBOBJS. (line 69) * endif: Conditionals. (line 41) * Example conditional --enable-debug: Conditionals. (line 26) * Example Hello World: Hello World. (line 6) * Example of recursive operation: General Operation. (line 44) * Example of shared libraries: Libtool Libraries. (line 6) * Example, EXTRA_PROGRAMS: Uniform. (line 36) * Example, false and true: true. (line 6) * Example, mixed language: Mixing Fortran 77 With C and C++. (line 36) * Executable extension: EXEEXT. (line 6) * Exit status 77, special interpretation: Tests. (line 19) * Expected test failure: Tests. (line 34) * Extending aclocal: Extending aclocal. (line 6) * Extending list of installation directories: Uniform. (line 55) * Extension, executable: EXEEXT. (line 6) * Extra files distributed with Automake: Invoking Automake. (line 39) * EXTRA_, prepending: Uniform. (line 29) * EXTRA_prog_SOURCES, defined: Conditional Sources. (line 18) * EXTRA_PROGRAMS, defined <1>: Conditional Programs. (line 15) * EXTRA_PROGRAMS, defined: Uniform. (line 36) * false Example: true. (line 6) * FCFLAGS and AM_FCFLAGS: Flag Variables Ordering. (line 20) * FDL, GNU Free Documentation License: GNU Free Documentation License. (line 6) * Features of the GNU Build System: Use Cases. (line 6) * FFLAGS and AM_FFLAGS: Flag Variables Ordering. (line 20) * file names, limitations on: limitations on file names. (line 6) * filename-length-max=99: Options. (line 48) * Files distributed with Automake: Invoking Automake. (line 39) * First line of Makefile.am: General Operation. (line 60) * Flag Variables, Ordering: Flag Variables Ordering. (line 20) * Flag variables, ordering: Flag Variables Ordering. (line 6) * FLIBS, defined: Mixing Fortran 77 With C and C++. (line 21) * foreign <1>: Options. (line 17) * foreign: amhello Explained. (line 38) * foreign strictness: Strictness. (line 10) * Fortran 77 support: Fortran 77 Support. (line 6) * Fortran 77, mixing with C and C++: Mixing Fortran 77 With C and C++. (line 6) * Fortran 77, Preprocessing: Preprocessing Fortran 77. (line 6) * Fortran 9x support: Fortran 9x Support. (line 6) * GCJFLAGS and AM_GCJFLAGS: Flag Variables Ordering. (line 20) * generated files and CVS: CVS. (line 49) * generated files, distributed: CVS. (line 9) * Gettext support: gettext. (line 6) * gnits: Options. (line 17) * gnits strictness: Strictness. (line 10) * gnu: Options. (line 17) * GNU Build System, basics: Basic Installation. (line 6) * GNU Build System, features: Use Cases. (line 6) * GNU Build System, introduction: GNU Build System. (line 6) * GNU Build System, use cases: Use Cases. (line 6) * GNU Coding Standards: GNU Build System. (line 29) * GNU Gettext support: gettext. (line 6) * GNU make extensions: General Operation. (line 19) * GNU Makefile standards: Introduction. (line 12) * gnu strictness: Strictness. (line 10) * GNUmakefile including Makefile: Third-Party Makefiles. (line 112) * Header files in _SOURCES: Program Sources. (line 39) * HEADERS primary, defined: Headers. (line 6) * HEADERS, installation directories: Headers. (line 6) * Hello World example: Hello World. (line 6) * hook targets: Extending. (line 61) * HP-UX 10, lex problems: Public macros. (line 86) * html <1>: Extending. (line 40) * html: Texinfo. (line 19) * HTML output using Texinfo: Texinfo. (line 6) * html-local: Extending. (line 40) * id: Tags. (line 44) * if: Conditionals. (line 41) * include <1>: Include. (line 6) * include: Dist. (line 17) * include, distribution: Dist. (line 17) * Including Makefile fragment: Include. (line 6) * info <1>: Extending. (line 40) * info: Options. (line 89) * info-local: Extending. (line 40) * install <1>: Extending. (line 40) * install <2>: Install. (line 45) * install: Standard Targets. (line 19) * Install hook: Install. (line 74) * Install, two parts of: Install. (line 45) * install-data <1>: Extending. (line 40) * install-data <2>: Install. (line 45) * install-data: Two-Part Install. (line 16) * install-data-hook: Extending. (line 64) * install-data-local <1>: Extending. (line 40) * install-data-local: Install. (line 68) * install-dvi <1>: Extending. (line 40) * install-dvi: Texinfo. (line 19) * install-dvi-local: Extending. (line 40) * install-exec <1>: Extending. (line 40) * install-exec <2>: Install. (line 45) * install-exec: Two-Part Install. (line 16) * install-exec-hook: Extending. (line 64) * install-exec-local <1>: Extending. (line 40) * install-exec-local: Install. (line 68) * install-html <1>: Extending. (line 40) * install-html: Texinfo. (line 19) * install-html-local: Extending. (line 40) * install-info <1>: Extending. (line 40) * install-info <2>: Options. (line 89) * install-info: Texinfo. (line 76) * install-info target: Texinfo. (line 76) * install-info-local: Extending. (line 40) * install-man <1>: Options. (line 95) * install-man: Man pages. (line 32) * install-man target: Man pages. (line 32) * install-pdf <1>: Extending. (line 40) * install-pdf: Texinfo. (line 19) * install-pdf-local: Extending. (line 40) * install-ps <1>: Extending. (line 40) * install-ps: Texinfo. (line 19) * install-ps-local: Extending. (line 40) * install-strip <1>: Install. (line 110) * install-strip: Standard Targets. (line 23) * Installation directories, extending list: Uniform. (line 55) * Installation support: Install. (line 6) * Installation, basics: Basic Installation. (line 6) * installcheck <1>: Extending. (line 40) * installcheck: Standard Targets. (line 40) * installcheck-local: Extending. (line 40) * installdirs <1>: Extending. (line 40) * installdirs: Install. (line 110) * installdirs-local: Extending. (line 40) * Installing headers: Headers. (line 6) * Installing scripts: Scripts. (line 6) * installing versioned binaries: Extending. (line 80) * Interfacing with third-party packages: Third-Party Makefiles. (line 6) * Invoking aclocal: Invoking aclocal. (line 6) * Invoking automake: Invoking Automake. (line 6) * JAVA primary, defined: Java. (line 6) * JAVA restrictions: Java. (line 19) * Java support: Java Support. (line 6) * LDADD and -l: Linking. (line 66) * LDFLAGS and AM_LDFLAGS: Flag Variables Ordering. (line 20) * lex problems with HP-UX 10: Public macros. (line 86) * lex, multiple lexers: Yacc and Lex. (line 64) * LFLAGS and AM_LFLAGS: Flag Variables Ordering. (line 20) * libltdl, introduction: Libtool Concept. (line 30) * LIBOBJS and ansi2knr: ANSI. (line 56) * LIBOBJS, and Libtool: LTLIBOBJS. (line 6) * LIBOBJS, example: LIBOBJS. (line 6) * LIBOBJS, special handling: LIBOBJS. (line 6) * LIBRARIES primary, defined: A Library. (line 6) * libtool convenience libraries: Libtool Convenience Libraries. (line 6) * libtool libraries, conditional: Conditional Libtool Libraries. (line 6) * libtool library, definition: Libtool Concept. (line 6) * libtool modules: Libtool Modules. (line 6) * Libtool modules, default source example: Default _SOURCES. (line 37) * libtool, introduction: Libtool Concept. (line 6) * LIBTOOLFLAGS and AM_LIBTOOLFLAGS: Flag Variables Ordering. (line 20) * libtoolize and autoreconf: Libtool Issues. (line 9) * libtoolize, no longer run by automake: Libtool Issues. (line 9) * Linking Fortran 77 with C and C++: Mixing Fortran 77 With C and C++. (line 6) * LISP primary, defined: Emacs Lisp. (line 6) * LN_S example: Extending. (line 80) * local targets: Extending. (line 36) * LTALLOCA, special handling: LTLIBOBJS. (line 6) * LTLIBOBJS and ansi2knr: ANSI. (line 56) * LTLIBOBJS, special handling: LTLIBOBJS. (line 6) * LTLIBRARIES primary, defined: Libtool Libraries. (line 6) * ltmain.sh not found: Libtool Issues. (line 9) * m4_include, distribution: Dist. (line 17) * Macro search path: Macro search path. (line 6) * macro serial numbers: Serials. (line 6) * Macros Automake recognizes: Optional. (line 6) * maintainer-clean-local: Clean. (line 15) * make check: Tests. (line 6) * make clean support: Clean. (line 6) * make dist: Dist. (line 9) * make distcheck: Dist. (line 111) * make distclean, diagnostic: distcleancheck. (line 6) * make distcleancheck: Dist. (line 111) * make distuninstallcheck: Dist. (line 111) * make install support: Install. (line 6) * make installcheck, testing --help and --version: Options. (line 115) * Make rules, overriding: General Operation. (line 32) * Make targets, overriding: General Operation. (line 32) * Makefile fragment, including: Include. (line 6) * Makefile.am, first line: General Operation. (line 60) * Makefile.am, Hello World: amhello Explained. (line 96) * MANS primary, defined: Man pages. (line 6) * many outputs, rules with: Multiple Outputs. (line 6) * mdate-sh: Texinfo. (line 29) * MinGW cross-compilation example: Cross-Compilation. (line 26) * missing, purpose: maintainer-mode. (line 9) * Mixed language example: Mixing Fortran 77 With C and C++. (line 36) * Mixing Fortran 77 with C and C++: Mixing Fortran 77 With C and C++. (line 6) * Mixing Fortran 77 with C and/or C++: Mixing Fortran 77 With C and C++. (line 6) * mkdir -p, macro check: Obsolete macros. (line 31) * modules, libtool: Libtool Modules. (line 6) * mostlyclean: Extending. (line 40) * mostlyclean-local <1>: Extending. (line 40) * mostlyclean-local: Clean. (line 15) * multiple configurations, example: VPATH Builds. (line 47) * Multiple configure.ac files: Invoking Automake. (line 6) * Multiple lex lexers: Yacc and Lex. (line 64) * multiple outputs, rules with: Multiple Outputs. (line 6) * Multiple yacc parsers: Yacc and Lex. (line 64) * Nested packages: Nested Packages. (line 6) * Nesting packages: Subpackages. (line 6) * no-define <1>: Options. (line 57) * no-define: Public macros. (line 54) * no-dependencies <1>: Options. (line 62) * no-dependencies: Dependencies. (line 34) * no-dist: Options. (line 69) * no-dist-gzip: Options. (line 73) * no-exeext: Options. (line 76) * no-installinfo <1>: Options. (line 86) * no-installinfo: Texinfo. (line 76) * no-installinfo option: Texinfo. (line 76) * no-installman <1>: Options. (line 92) * no-installman: Man pages. (line 32) * no-installman option: Man pages. (line 32) * no-texinfo.tex <1>: Options. (line 102) * no-texinfo.tex: Texinfo. (line 71) * nobase_ and dist_ or nodist_: Alternative. (line 30) * nobase_ prefix: Alternative. (line 24) * nodist_ and nobase_: Alternative. (line 30) * noinst_ primary prefix, definition: Uniform. (line 69) * Non-GNU packages: Strictness. (line 6) * Non-standard targets: General Operation. (line 12) * nostdinc: Options. (line 98) * OBJCFLAGS and AM_OBJCFLAGS: Flag Variables Ordering. (line 20) * Objective C support: Objective C Support. (line 6) * Objects in subdirectory: Program and Library Variables. (line 51) * obsolete macros: Obsolete macros. (line 6) * optimized build, example: VPATH Builds. (line 47) * Option, --warnings=CATEGORY: Options. (line 197) * Option, -WCATEGORY: Options. (line 197) * Option, ansi2knr: Options. (line 22) * Option, check-news: Options. (line 29) * Option, cygnus: Options. (line 17) * Option, dejagnu: Options. (line 33) * Option, dist-bzip2: Options. (line 36) * Option, dist-shar: Options. (line 39) * Option, dist-tarZ: Options. (line 45) * Option, dist-zip: Options. (line 42) * Option, filename-length-max=99: Options. (line 48) * Option, foreign: Options. (line 17) * Option, gnits: Options. (line 17) * Option, gnu: Options. (line 17) * Option, no-define: Options. (line 57) * Option, no-dependencies: Options. (line 62) * Option, no-dist: Options. (line 69) * Option, no-dist-gzip: Options. (line 73) * Option, no-exeext: Options. (line 76) * Option, no-installinfo <1>: Options. (line 86) * Option, no-installinfo: Texinfo. (line 76) * Option, no-installman <1>: Options. (line 92) * Option, no-installman: Man pages. (line 32) * Option, no-texinfo.tex: Options. (line 102) * Option, nostdinc: Options. (line 98) * Option, readme-alpha: Options. (line 106) * Option, tar-pax: Options. (line 147) * Option, tar-ustar: Options. (line 147) * Option, tar-v7: Options. (line 147) * Option, VERSION: Options. (line 192) * Option, warnings: Options. (line 197) * Options, aclocal: aclocal options. (line 6) * Options, automake: Invoking Automake. (line 37) * Options, std-options: Options. (line 115) * Options, subdir-objects: Options. (line 135) * Ordering flag variables: Flag Variables Ordering. (line 6) * Overriding make rules: General Operation. (line 32) * Overriding make targets: General Operation. (line 32) * Overriding make variables: General Operation. (line 37) * overriding rules: Extending. (line 25) * overriding semantics: Extending. (line 25) * PACKAGE, directory: Uniform. (line 19) * PACKAGE, prevent definition: Public macros. (line 54) * Packages, nested: Nested Packages. (line 6) * Packages, preparation: Preparing Distributions. (line 6) * Parallel build trees: VPATH Builds. (line 6) * Path stripping, avoiding: Alternative. (line 24) * pax format: Options. (line 147) * pdf <1>: Extending. (line 40) * pdf: Texinfo. (line 19) * PDF output using Texinfo: Texinfo. (line 6) * pdf-local: Extending. (line 40) * Per-object flags, emulated: Per-Object Flags. (line 6) * per-target compilation flags, defined: Program and Library Variables. (line 171) * pkgdatadir, defined: Uniform. (line 19) * pkgincludedir, defined: Uniform. (line 19) * pkglibdir, defined: Uniform. (line 19) * POSIX termios headers: Obsolete macros. (line 53) * Preparing distributions: Preparing Distributions. (line 6) * Preprocessing Fortran 77: Preprocessing Fortran 77. (line 6) * Primary variable, DATA: Data. (line 6) * Primary variable, defined: Uniform. (line 11) * Primary variable, HEADERS: Headers. (line 6) * Primary variable, JAVA: Java. (line 6) * Primary variable, LIBRARIES: A Library. (line 6) * Primary variable, LISP: Emacs Lisp. (line 6) * Primary variable, LTLIBRARIES: Libtool Libraries. (line 6) * Primary variable, MANS: Man pages. (line 6) * Primary variable, PROGRAMS: Uniform. (line 11) * Primary variable, PYTHON: Python. (line 6) * Primary variable, SCRIPTS: Scripts. (line 6) * Primary variable, SOURCES: Program Sources. (line 32) * Primary variable, TEXINFOS: Texinfo. (line 6) * prog_LDADD, defined: Linking. (line 12) * PROGRAMS primary variable: Uniform. (line 11) * Programs, auxiliary: Auxiliary Programs. (line 6) * PROGRAMS, bindir: Program Sources. (line 6) * Programs, conditional: Conditional Programs. (line 6) * Programs, renaming during installation: Renaming. (line 6) * Proxy Makefile for third-party packages: Third-Party Makefiles. (line 129) * ps <1>: Extending. (line 40) * ps: Texinfo. (line 19) * PS output using Texinfo: Texinfo. (line 6) * ps-local: Extending. (line 40) * PYTHON primary, defined: Python. (line 6) * Ratfor programs: Preprocessing Fortran 77. (line 6) * read-only source tree: VPATH Builds. (line 90) * README-alpha: Gnits. (line 34) * readme-alpha: Options. (line 106) * rebuild rules <1>: CVS. (line 9) * rebuild rules: Rebuilding. (line 6) * Recognized macros by Automake: Optional. (line 6) * Recursive operation of Automake: General Operation. (line 44) * recursive targets and third-party Makefiles: Third-Party Makefiles. (line 15) * regex package: Public macros. (line 107) * Renaming programs: Renaming. (line 6) * Reporting bugs: Introduction. (line 31) * Requirements of Automake: Requirements. (line 6) * Requirements, Automake: Introduction. (line 27) * Restrictions for JAVA: Java. (line 19) * RFLAGS and AM_RFLAGS: Flag Variables Ordering. (line 20) * rules with multiple outputs: Multiple Outputs. (line 6) * rules, conflicting: Extending. (line 14) * rules, overriding: Extending. (line 25) * rx package: Public macros. (line 107) * Scanning configure.ac: configure. (line 6) * SCRIPTS primary, defined: Scripts. (line 6) * SCRIPTS, installation directories: Scripts. (line 18) * Selecting the linker automatically: How the Linker is Chosen. (line 6) * serial number and --install: aclocal options. (line 32) * serial numbers in macros: Serials. (line 6) * Shared libraries, support for: A Shared Library. (line 6) * site.exp: Tests. (line 77) * source tree and build tree: VPATH Builds. (line 6) * source tree, read-only: VPATH Builds. (line 90) * SOURCES primary, defined: Program Sources. (line 32) * Special Automake comment: General Operation. (line 54) * Staged installation: DESTDIR. (line 14) * std-options: Options. (line 115) * Strictness, command line: Invoking Automake. (line 37) * Strictness, defined: Strictness. (line 10) * Strictness, foreign: Strictness. (line 10) * Strictness, gnits: Strictness. (line 10) * Strictness, gnu: Strictness. (line 10) * su, before make install: Basic Installation. (line 50) * subdir-objects: Options. (line 135) * Subdirectories, building conditionally: Conditional Subdirectories. (line 6) * Subdirectories, configured conditionally: Conditional Subdirectories. (line 119) * Subdirectories, not distributed: Conditional Subdirectories. (line 170) * Subdirectory, objects in: Program and Library Variables. (line 51) * SUBDIRS and AC_SUBST: Conditional Subdirectories. (line 95) * SUBDIRS and AM_CONDITIONAL: Conditional Subdirectories. (line 65) * SUBDIRS, conditional: Conditional Subdirectories. (line 6) * SUBDIRS, explained: Subdirectories. (line 6) * Subpackages <1>: Subpackages. (line 6) * Subpackages: Nested Packages. (line 6) * suffix .la, defined: Libtool Concept. (line 6) * suffix .lo, defined: Libtool Concept. (line 15) * SUFFIXES, adding: Suffixes. (line 6) * Support for C++: C++ Support. (line 6) * Support for Fortran 77: Fortran 77 Support. (line 6) * Support for Fortran 9x: Fortran 9x Support. (line 6) * Support for GNU Gettext: gettext. (line 6) * Support for Java: Java Support. (line 6) * Support for Objective C: Objective C Support. (line 6) * Support for Unified Parallel C: Unified Parallel C Support. (line 6) * tags: Tags. (line 9) * TAGS support: Tags. (line 6) * tar formats: Options. (line 147) * tar-pax: Options. (line 147) * tar-ustar: Options. (line 147) * tar-v7: Options. (line 147) * Target, install-info: Texinfo. (line 76) * Target, install-man: Man pages. (line 32) * termios POSIX headers: Obsolete macros. (line 53) * Test suites: Tests. (line 6) * Tests, expected failure: Tests. (line 34) * Texinfo flag, EDITION: Texinfo. (line 29) * Texinfo flag, UPDATED: Texinfo. (line 29) * Texinfo flag, UPDATED-MONTH: Texinfo. (line 29) * Texinfo flag, VERSION: Texinfo. (line 29) * texinfo.tex: Texinfo. (line 64) * TEXINFOS primary, defined: Texinfo. (line 6) * third-party files and CVS: CVS. (line 140) * Third-party packages, interfacing with: Third-Party Makefiles. (line 6) * timestamps and CVS: CVS. (line 28) * Transforming program names: Renaming. (line 6) * trees, source vs. build: VPATH Builds. (line 6) * true Example: true. (line 6) * underquoted AC_DEFUN: Extending aclocal. (line 33) * Unified Parallel C support: Unified Parallel C Support. (line 6) * Uniform naming scheme: Uniform. (line 6) * uninstall <1>: Extending. (line 40) * uninstall <2>: Install. (line 110) * uninstall: Standard Targets. (line 27) * uninstall-hook: Extending. (line 64) * uninstall-local: Extending. (line 40) * Unpacking: Basic Installation. (line 27) * UPCFLAGS and AM_UPCFLAGS: Flag Variables Ordering. (line 20) * UPDATED Texinfo flag: Texinfo. (line 29) * UPDATED-MONTH Texinfo flag: Texinfo. (line 29) * Use Cases for the GNU Build System: Use Cases. (line 6) * user variables: User Variables. (line 6) * ustar format: Options. (line 147) * v7 tar format: Options. (line 147) * variables, conflicting: Extending. (line 14) * Variables, overriding: General Operation. (line 37) * variables, reserved for the user: User Variables. (line 6) * VERSION Texinfo flag: Texinfo. (line 29) * VERSION, prevent definition: Public macros. (line 54) * version.m4, example: Rebuilding. (line 19) * version.sh, example: Rebuilding. (line 19) * versioned binaries, installing: Extending. (line 80) * VPATH builds: VPATH Builds. (line 6) * wildcards: wildcards. (line 6) * Windows: EXEEXT. (line 6) * yacc, multiple parsers: Yacc and Lex. (line 64) * YFLAGS and AM_YFLAGS: Flag Variables Ordering. (line 20) * ylwrap: Yacc and Lex. (line 64) * zardoz example: Complete. (line 35)