1 This is ../../automake/doc/automake.info, produced by makeinfo version
2 4.11.90 from ../../automake/doc/automake.texi.
4 This manual is for GNU Automake (version 1.11.1, 8 December 2009), a
5 program that creates GNU standards-compliant Makefiles from template
8 Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
9 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, Inc.
11 Permission is granted to copy, distribute and/or modify this
12 document under the terms of the GNU Free Documentation License,
13 Version 1.3 or any later version published by the Free Software
14 Foundation; with no Invariant Sections, with no Front-Cover texts,
15 and with no Back-Cover Texts. A copy of the license is included
16 in the section entitled "GNU Free Documentation License."
19 INFO-DIR-SECTION Software development
21 * Automake: (automake). Making GNU standards-compliant Makefiles.
24 INFO-DIR-SECTION Individual utilities
26 * aclocal: (automake)Invoking aclocal. Generating aclocal.m4.
27 * automake: (automake)Invoking Automake. Generating Makefile.in.
31 File: automake.info, Node: Simple Tests using parallel-tests, Next: DejaGnu Tests, Prev: Simple Tests, Up: Tests
33 15.2 Simple Tests using `parallel-tests'
34 ========================================
36 The option `parallel-tests' (*note Options::) enables a test suite
37 driver that is mostly compatible to the simple test driver described in
38 the previous section, but provides a few more features and slightly
39 different semantics. It features concurrent execution of tests with
40 `make -j', allows to specify inter-test dependencies, lazy reruns of
41 tests that have not completed in a prior run, summary and verbose
42 output in `RST' (reStructuredText) and `HTML' format, and hard errors
43 for exceptional failures. Similar to the simple test driver,
44 `TESTS_ENVIRONMENT', `AM_COLOR_TESTS', `XFAIL_TESTS', and the `check_*'
45 variables are honored, and the environment variable `srcdir' is set
46 during test execution.
48 This test driver is still experimental and may undergo changes in
49 order to satisfy additional portability requirements.
51 The driver operates by defining a set of `make' rules to create a
52 summary log file, `TEST_SUITE_LOG', which defaults to `test-suite.log'
53 and requires a `.log' suffix. This file depends upon log files created
54 for each single test program listed in `TESTS', which in turn contain
55 all output produced by the corresponding tests.
57 Each log file is created when the corresponding test has completed.
58 The set of log files is listed in the read-only variable `TEST_LOGS',
59 and defaults to `TESTS', with the executable extension if any (*note
60 EXEEXT::), as well as any suffix listed in `TEST_EXTENSIONS' removed,
61 and `.log' appended. `TEST_EXTENSIONS' defaults to `.test'. Results
62 are undefined if a test file name ends in several concatenated suffixes.
64 For tests that match an extension `.EXT' listed in
65 `TEST_EXTENSIONS', you can provide a test driver using the variable
66 `EXT_LOG_COMPILER' (note the upper-case extension) and pass options in
67 `AM_EXT_LOG_FLAGS' and allow the user to pass options in
68 `EXT_LOG_FLAGS'. It will cause all tests with this extension to be
69 called with this driver. For all tests without a registered extension,
70 the variables `LOG_COMPILER', `AM_LOG_FLAGS', and `LOG_FLAGS' may be
73 TESTS = foo.pl bar.py baz
74 TEST_EXTENSIONS = .pl .py
75 PL_LOG_COMPILER = $(PERL)
77 PY_LOG_COMPILER = $(PYTHON)
79 LOG_COMPILER = ./wrapper-script
82 will invoke `$(PERL) -w foo.pl', `$(PYTHON) -v bar.py', and
83 `./wrapper-script -d baz' to produce `foo.log', `bar.log', and
84 `baz.log', respectively. The `TESTS_ENVIRONMENT' variable is still
85 expanded before the driver, but should be reserved for the user.
87 As with the simple driver above, by default one status line is
88 printed per completed test, and a short summary after the suite has
89 completed. However, standard output and standard error of the test are
90 redirected to a per-test log file, so that parallel execution does not
91 produce intermingled output. The output from failed tests is collected
92 in the `test-suite.log' file. If the variable `VERBOSE' is set, this
93 file is output after the summary. For best results, the tests should be
94 verbose by default now.
96 With `make check-html', the log files may be converted from RST
97 (reStructuredText, see `http://docutils.sourceforge.net/rst.html') to
98 HTML using `RST2HTML', which defaults to `rst2html' or `rst2html.py'.
99 The variable `TEST_SUITE_HTML' contains the set of converted log files.
100 The log and HTML files are removed upon `make mostlyclean'.
102 Even in the presence of expected failures (see `XFAIL_TESTS', there
103 may be conditions under which a test outcome needs attention. For
104 example, with test-driven development, you may write tests for features
105 that you have not implemented yet, and thus mark these tests as expected
106 to fail. However, you may still be interested in exceptional
107 conditions, for example, tests that fail due to a segmentation
108 violation or another error that is independent of the feature awaiting
109 implementation. Tests can exit with an exit status of 99 to signal
110 such a _hard error_. Unless the variable `DISABLE_HARD_ERRORS' is set
111 to a nonempty value, such tests will be counted as failed.
113 By default, the test suite driver will run all tests, but there are
114 several ways to limit the set of tests that are run:
116 * You can set the `TESTS' variable, similarly to how you can with
117 the simple test driver from the previous section. For example,
118 you can use a command like this to run only a subset of the tests:
120 env TESTS="foo.test bar.test" make -e check
122 * You can set the `TEST_LOGS' variable. By default, this variable is
123 computed at `make' run time from the value of `TESTS' as described
124 above. For example, you can use the following:
126 set x subset*.log; shift
127 env TEST_LOGS="foo.log $*" make -e check
129 * By default, the test driver removes all old per-test log files
130 before it starts running tests to regenerate them. The variable
131 `RECHECK_LOGS' contains the set of log files which are removed.
132 `RECHECK_LOGS' defaults to `TEST_LOGS', which means all tests need
133 to be rechecked. By overriding this variable, you can choose which
134 tests need to be reconsidered. For example, you can lazily rerun
135 only those tests which are outdated, i.e., older than their
136 prerequisite test files, by setting this variable to the empty
139 env RECHECK_LOGS= make -e check
141 * You can ensure that all tests are rerun which have failed or passed
142 unexpectedly, by running `make recheck' in the test directory.
143 This convenience target will set `RECHECK_LOGS' appropriately
144 before invoking the main test driver. The `recheck-html' target
145 does the same as `recheck' but again converts the resulting log
146 file in HTML format, like the `check-html' target.
148 In order to guarantee an ordering between tests even with `make
149 -jN', dependencies between the corresponding log files may be specified
150 through usual `make' dependencies. For example, the following snippet
151 lets the test named `foo-execute.test' depend upon completion of the
152 test `foo-compile.test':
154 TESTS = foo-compile.test foo-execute.test
155 foo-execute.log: foo-compile.log
157 Please note that this ordering ignores the _results_ of required tests,
158 thus the test `foo-execute.test' is run even if the test
159 `foo-compile.test' failed or was skipped beforehand. Further, please
160 note that specifying such dependencies currently works only for tests
161 that end in one of the suffixes listed in `TEST_EXTENSIONS'.
163 Tests without such specified dependencies may be run concurrently
164 with parallel `make -jN', so be sure they are prepared for concurrent
167 The combination of lazy test execution and correct dependencies
168 between tests and their sources may be exploited for efficient unit
169 testing during development. To further speed up the edit-compile-test
170 cycle, it may even be useful to specify compiled programs in
171 `EXTRA_PROGRAMS' instead of with `check_PROGRAMS', as the former allows
172 intertwined compilation and test execution (but note that
173 `EXTRA_PROGRAMS' are not cleaned automatically, *note Uniform::).
175 The variables `TESTS' and `XFAIL_TESTS' may contain conditional
176 parts as well as configure substitutions. In the latter case, however,
177 certain restrictions apply: substituted test names must end with a
178 nonempty test suffix like `.test', so that one of the inference rules
179 generated by `automake' can apply. For literal test names, `automake'
180 can generate per-target rules to avoid this limitation.
182 Please note that it is currently not possible to use `$(srcdir)/' or
183 `$(top_srcdir)/' in the `TESTS' variable. This technical limitation is
184 necessary to avoid generating test logs in the source tree and has the
185 unfortunate consequence that it is not possible to specify distributed
186 tests that are themselves generated by means of explicit rules, in a
187 way that is portable to all `make' implementations (*note Make Target
188 Lookup: (autoconf)Make Target Lookup, the semantics of FreeBSD and
189 OpenBSD `make' conflict with this). In case of doubt you may want to
190 require to use GNU `make', or work around the issue with inference
191 rules to generate the tests.
194 File: automake.info, Node: DejaGnu Tests, Next: Install Tests, Prev: Simple Tests using parallel-tests, Up: Tests
199 If `dejagnu' (ftp://ftp.gnu.org/gnu/dejagnu/) appears in
200 `AUTOMAKE_OPTIONS', then a `dejagnu'-based test suite is assumed. The
201 variable `DEJATOOL' is a list of names that are passed, one at a time,
202 as the `--tool' argument to `runtest' invocations; it defaults to the
205 The variable `RUNTESTDEFAULTFLAGS' holds the `--tool' and `--srcdir'
206 flags that are passed to dejagnu by default; this can be overridden if
209 The variables `EXPECT' and `RUNTEST' can also be overridden to
210 provide project-specific values. For instance, you will need to do
211 this if you are testing a compiler toolchain, because the default
212 values do not take into account host and target names.
214 The contents of the variable `RUNTESTFLAGS' are passed to the
215 `runtest' invocation. This is considered a "user variable" (*note User
216 Variables::). If you need to set `runtest' flags in `Makefile.am', you
217 can use `AM_RUNTESTFLAGS' instead.
219 Automake will generate rules to create a local `site.exp' file,
220 defining various variables detected by `configure'. This file is
221 automatically read by DejaGnu. It is OK for the user of a package to
222 edit this file in order to tune the test suite. However this is not
223 the place where the test suite author should define new variables: this
224 should be done elsewhere in the real test suite code. Especially,
225 `site.exp' should not be distributed.
227 For more information regarding DejaGnu test suites, see *note Top:
230 In either case, the testing is done via `make check'.
233 File: automake.info, Node: Install Tests, Prev: DejaGnu Tests, Up: Tests
238 The `installcheck' target is available to the user as a way to run any
239 tests after the package has been installed. You can add tests to this
240 by writing an `installcheck-local' rule.
243 File: automake.info, Node: Rebuilding, Next: Options, Prev: Tests, Up: Top
245 16 Rebuilding Makefiles
246 ***********************
248 Automake generates rules to automatically rebuild `Makefile's,
249 `configure', and other derived files like `Makefile.in'.
251 If you are using `AM_MAINTAINER_MODE' in `configure.ac', then these
252 automatic rebuilding rules are only enabled in maintainer mode.
254 Sometimes you need to run `aclocal' with an argument like `-I' to
255 tell it where to find `.m4' files. Since sometimes `make' will
256 automatically run `aclocal', you need a way to specify these arguments.
257 You can do this by defining `ACLOCAL_AMFLAGS'; this holds arguments
258 that are passed verbatim to `aclocal'. This variable is only useful in
259 the top-level `Makefile.am'.
261 Sometimes it is convenient to supplement the rebuild rules for
262 `configure' or `config.status' with additional dependencies. The
263 variables `CONFIGURE_DEPENDENCIES' and `CONFIG_STATUS_DEPENDENCIES' can
264 be used to list these extra dependencies. These variable should be
265 defined in all `Makefile's of the tree (because these two rebuild rules
266 are output in all them), so it is safer and easier to `AC_SUBST' them
267 from `configure.ac'. For instance, the following statement will cause
268 `configure' to be rerun each time `version.sh' is changed.
269 AC_SUBST([CONFIG_STATUS_DEPENDENCIES], ['$(top_srcdir)/version.sh'])
270 Note the `$(top_srcdir)/' in the file name. Since this variable is
271 to be used in all `Makefile's, its value must be sensible at any level
272 in the build hierarchy.
274 Beware not to mistake `CONFIGURE_DEPENDENCIES' for
275 `CONFIG_STATUS_DEPENDENCIES'.
277 `CONFIGURE_DEPENDENCIES' adds dependencies to the `configure' rule,
278 whose effect is to run `autoconf'. This variable should be seldom
279 used, because `automake' already tracks `m4_include'd files. However
280 it can be useful when playing tricky games with `m4_esyscmd' or similar
281 non-recommendable macros with side effects.
283 `CONFIG_STATUS_DEPENDENCIES' adds dependencies to the
284 `config.status' rule, whose effect is to run `configure'. This
285 variable should therefore carry any non-standard source that may be
286 read as a side effect of running `configure', like `version.sh' in the
289 Speaking of `version.sh' scripts, we recommend against them today.
290 They are mainly used when the version of a package is updated
291 automatically by a script (e.g., in daily builds). Here is what some
292 old-style `configure.ac's may look like:
295 AM_INIT_AUTOMAKE([name], $VERSION_NUMBER)
297 Here, `version.sh' is a shell fragment that sets `VERSION_NUMBER'.
298 The problem with this example is that `automake' cannot track
299 dependencies (listing `version.sh' in `CONFIG_STATUS_DEPENDENCIES', and
300 distributing this file is up to the user), and that it uses the
301 obsolete form of `AC_INIT' and `AM_INIT_AUTOMAKE'. Upgrading to the
302 new syntax is not straightforward, because shell variables are not
303 allowed in `AC_INIT''s arguments. We recommend that `version.sh' be
304 replaced by an M4 file that is included by `configure.ac':
305 m4_include([version.m4])
306 AC_INIT([name], VERSION_NUMBER)
309 Here `version.m4' could contain something like
310 `m4_define([VERSION_NUMBER], [1.2])'. The advantage of this second
311 form is that `automake' will take care of the dependencies when
312 defining the rebuild rule, and will also distribute the file
313 automatically. An inconvenience is that `autoconf' will now be rerun
314 each time the version number is bumped, when only `configure' had to be
315 rerun in the previous setup.
318 File: automake.info, Node: Options, Next: Miscellaneous, Prev: Rebuilding, Up: Top
320 17 Changing Automake's Behavior
321 *******************************
323 Various features of Automake can be controlled by options. Except where
324 noted otherwise, options can be specified in one of several ways: Most
325 options can be applied on a per-`Makefile' basis when listed in a
326 special `Makefile' variable named `AUTOMAKE_OPTIONS'. Some of these
327 options only make sense when specified in the toplevel `Makefile.am'
328 file. Options are applied globally to all processed `Makefile' files
329 when listed in the first argument of `AM_INIT_AUTOMAKE' in
330 `configure.ac', and some options which require changes to the
331 `configure' script can only be specified there. These are annotated
334 Currently understood options are:
340 Set the strictness as appropriate. The `gnits' option also
341 implies options `readme-alpha' and `check-news'.
345 Turn on the obsolete de-ANSI-fication feature. *Note ANSI::. If
346 preceded by a path, the generated `Makefile.in' will look in the
347 specified directory to find the `ansi2knr' program. The path
348 should be a relative path to another directory in the same
349 distribution (Automake currently does not check this).
352 Cause `make dist' to fail unless the current version number appears
353 in the first few lines of the `NEWS' file.
356 Cause output of the simple test suite (*note Simple Tests::) to be
357 colorized on capable terminals.
360 Cause `dejagnu'-specific rules to be generated. *Note DejaGnu
364 Hook `dist-bzip2' to `dist'.
367 Hook `dist-lzma' to `dist'.
370 Hook `dist-shar' to `dist'.
373 Hook `dist-zip' to `dist'.
376 Hook `dist-tarZ' to `dist'.
378 `filename-length-max=99'
379 Abort if file names longer than 99 characters are found during
380 `make dist'. Such long file names are generally considered not to
381 be portable in tarballs. See the `tar-v7' and `tar-ustar' options
382 below. This option should be used in the top-level `Makefile.am'
383 or as an argument of `AM_INIT_AUTOMAKE' in `configure.ac', it will
384 be ignored otherwise. It will also be ignored in sub-packages of
385 nested packages (*note Subpackages::).
388 This option is meaningful only when passed as an argument to
389 `AM_INIT_AUTOMAKE'. It will prevent the `PACKAGE' and `VERSION'
390 variables from being `AC_DEFINE'd.
393 This is similar to using `--ignore-deps' on the command line, but
394 is useful for those situations where you don't have the necessary
395 bits to make automatic dependency tracking work (*note
396 Dependencies::). In this case the effect is to effectively
397 disable automatic dependency tracking.
400 Don't emit any code related to `dist' target. This is useful when
401 a package has its own method for making distributions.
404 Do not hook `dist-gzip' to `dist'.
407 If your `Makefile.am' defines a rule for target `foo', it will
408 override a rule for a target named `foo$(EXEEXT)'. This is
409 necessary when `EXEEXT' is found to be empty. However, by default
410 `automake' will generate an error for this use. The `no-exeext'
411 option will disable this error. This is intended for use only
412 where it is known in advance that the package will not be ported
413 to Windows, or any other operating system using extensions on
417 The generated `Makefile.in' will not cause info pages to be built
418 or installed by default. However, `info' and `install-info'
419 targets will still be available. This option is disallowed at
420 `gnu' strictness and above.
423 The generated `Makefile.in' will not cause man pages to be
424 installed by default. However, an `install-man' target will still
425 be available for optional installation. This option is disallowed
426 at `gnu' strictness and above.
429 This option can be used to disable the standard `-I' options that
430 are ordinarily automatically provided by Automake.
433 Don't require `texinfo.tex', even if there are texinfo files in
437 Enable test suite driver for `TESTS' that can run tests in parallel
438 (*note Simple Tests using parallel-tests::, for more information).
441 If this release is an alpha release, and the file `README-alpha'
442 exists, then it will be added to the distribution. If this option
443 is given, version numbers are expected to follow one of two forms.
444 The first form is `MAJOR.MINOR.ALPHA', where each element is a
445 number; the final period and number should be left off for
446 non-alpha releases. The second form is `MAJOR.MINORALPHA', where
447 ALPHA is a letter; it should be omitted for non-alpha releases.
450 Enable less verbose build rules. This can be used to let build
451 rules output a status line of the form
455 instead of printing the command that will be executed to update
456 OUTPUT-FILE. It can also silence `libtool' output.
458 To enable less verbose build rules, both the developer and the user
459 of the package have to take a number of steps. The developer needs
460 to do either of the following:
462 * Add the `silent-rules' option as argument to
465 * Call the `AM_SILENT_RULES' macro from within the
468 It is not possible to instead specify `silent-rules' in a
471 If the developer has done either of the above, then the user of the
472 package may influence the verbosity at `configure' run time as
473 well as at `make' run time:
475 * Passing `--enable-silent-rules' to `configure' will cause
476 build rules to be less verbose; the option
477 `--disable-silent-rules' is the default and will cause normal
480 * At `make' run time, the default chosen at `configure' time
481 may be overridden: `make V=1' will produce verbose output,
482 `make V=0' less verbose output.
484 For portability to different `make' implementations, package
485 authors are advised to not set the variable `V' inside the
486 `Makefile.am' file, to allow the user to override the value for
487 subdirectories as well.
489 The current implementation of this feature relies on a non-POSIX,
490 but in practice rather widely supported `Makefile' construct of
491 nested variable expansion `$(VAR1$(V))'. Do not use the
492 `silent-rules' option if your package needs to build with `make'
493 implementations that do not support it. The `silent-rules' option
494 turns off warnings about recursive variable expansion, which are
495 in turn enabled by `-Wportability' (*note Invoking Automake::).
497 To extend the silent mode to your own rules, you have two choices:
499 * You can use the predefined variable `AM_V_GEN' as a prefix to
500 commands that should output a status line in silent mode, and
501 `AM_V_at' as a prefix to commands that should not output
502 anything in silent mode. When output is to be verbose, both
503 of these variables will expand to the empty string.
505 * You can add your own variables, so strings of your own choice
506 are shown. The following snippet shows how you would define
507 your own equivalent of `AM_V_GEN':
509 pkg_verbose = $(pkg_verbose_$(V))
510 pkg_verbose_ = $(pkg_verbose_$(AM_DEFAULT_VERBOSITY))
511 pkg_verbose_0 = @echo GEN $@;
514 $(pkg_verbose)cp $(srcdir)/foo.in $@
517 Make the `installcheck' rule check that installed scripts and
518 programs support the `--help' and `--version' options. This also
519 provides a basic check that the program's run-time dependencies
520 are satisfied after installation.
522 In a few situations, programs (or scripts) have to be exempted
523 from this test. For instance, `false' (from GNU coreutils) is
524 never successful, even for `--help' or `--version'. You can list
525 such programs in the variable `AM_INSTALLCHECK_STD_OPTIONS_EXEMPT'.
526 Programs (not scripts) listed in this variable should be suffixed
527 by `$(EXEEXT)' for the sake of Win32 or OS/2. For instance,
528 suppose we build `false' as a program but `true.sh' as a script,
529 and that neither of them support `--help' or `--version':
531 AUTOMAKE_OPTIONS = std-options
532 bin_PROGRAMS = false ...
533 bin_SCRIPTS = true.sh ...
534 AM_INSTALLCHECK_STD_OPTIONS_EXEMPT = false$(EXEEXT) true.sh
537 If this option is specified, then objects are placed into the
538 subdirectory of the build directory corresponding to the
539 subdirectory of the source file. For instance, if the source file
540 is `subdir/file.cxx', then the output file would be
543 In order to use this option with C sources, you should add
544 `AM_PROG_CC_C_O' to `configure.ac'.
549 These three mutually exclusive options select the tar format to use
550 when generating tarballs with `make dist'. (The tar file created
551 is then compressed according to the set of `no-dist-gzip',
552 `dist-bzip2', `dist-lzma' and `dist-tarZ' options in use.)
554 These options must be passed as arguments to `AM_INIT_AUTOMAKE'
555 (*note Macros::) because they can require additional configure
556 checks. Automake will complain if it sees such options in an
557 `AUTOMAKE_OPTIONS' variable.
559 `tar-v7' selects the old V7 tar format. This is the historical
560 default. This antiquated format is understood by all tar
561 implementations and supports file names with up to 99 characters.
562 When given longer file names some tar implementations will
563 diagnose the problem while other will generate broken tarballs or
564 use non-portable extensions. Furthermore, the V7 format cannot
565 store empty directories. When using this format, consider using
566 the `filename-length-max=99' option to catch file names too long.
568 `tar-ustar' selects the ustar format defined by POSIX 1003.1-1988.
569 This format is believed to be old enough to be portable. It fully
570 supports empty directories. It can store file names with up to
571 256 characters, provided that the file name can be split at
572 directory separator in two parts, first of them being at most 155
573 bytes long. So, in most cases the maximum file name length will be
574 shorter than 256 characters. However you may run against broken
575 tar implementations that incorrectly handle file names longer than
576 99 characters (please report them to <bug-automake@gnu.org> so we
577 can document this accurately).
579 `tar-pax' selects the new pax interchange format defined by POSIX
580 1003.1-2001. It does not limit the length of file names. However,
581 this format is very young and should probably be restricted to
582 packages that target only very modern platforms. There are moves
583 to change the pax format in an upward-compatible way, so this
584 option may refer to a more recent version in the future.
586 *Note Controlling the Archive Format: (tar)Formats, for further
587 discussion about tar formats.
589 `configure' knows several ways to construct these formats. It
590 will not abort if it cannot find a tool up to the task (so that the
591 package can still be built), but `make dist' will fail.
594 A version number (e.g., `0.30') can be specified. If Automake is
595 not newer than the version specified, creation of the `Makefile.in'
598 `-WCATEGORY' or `--warnings=CATEGORY'
599 These options behave exactly like their command-line counterpart
600 (*note Invoking Automake::). This allows you to enable or disable
601 some warning categories on a per-file basis. You can also setup
602 some warnings for your entire project; for instance, try
603 `AM_INIT_AUTOMAKE([-Wall])' in your `configure.ac'.
606 Unrecognized options are diagnosed by `automake'.
608 If you want an option to apply to all the files in the tree, you can
609 use the `AM_INIT_AUTOMAKE' macro in `configure.ac'. *Note Macros::.
612 File: automake.info, Node: Miscellaneous, Next: Include, Prev: Options, Up: Top
614 18 Miscellaneous Rules
615 **********************
617 There are a few rules and variables that didn't fit anywhere else.
621 * Tags:: Interfacing to etags and mkid
622 * Suffixes:: Handling new file extensions
623 * Multilibs:: Support for multilibs.
626 File: automake.info, Node: Tags, Next: Suffixes, Up: Miscellaneous
628 18.1 Interfacing to `etags'
629 ===========================
631 Automake will generate rules to generate `TAGS' files for use with GNU
632 Emacs under some circumstances.
634 If any C, C++ or Fortran 77 source code or headers are present, then
635 `tags' and `TAGS' rules will be generated for the directory. All files
636 listed using the `_SOURCES', `_HEADERS', and `_LISP' primaries will be
637 used to generate tags. Note that generated source files that are not
638 distributed must be declared in variables like `nodist_noinst_HEADERS'
639 or `nodist_PROG_SOURCES' or they will be ignored.
641 A `tags' rule will be output at the topmost directory of a
642 multi-directory package. When run from this topmost directory, `make
643 tags' will generate a `TAGS' file that includes by reference all `TAGS'
644 files from subdirectories.
646 The `tags' rule will also be generated if the variable `ETAGS_ARGS'
647 is defined. This variable is intended for use in directories that
648 contain taggable source that `etags' does not understand. The user can
649 use the `ETAGSFLAGS' to pass additional flags to `etags';
650 `AM_ETAGSFLAGS' is also available for use in `Makefile.am'.
652 Here is how Automake generates tags for its source, and for nodes in
655 ETAGS_ARGS = automake.in --lang=none \
656 --regex='/^@node[ \t]+\([^,]+\)/\1/' automake.texi
658 If you add file names to `ETAGS_ARGS', you will probably also want
659 to define `TAGS_DEPENDENCIES'. The contents of this variable are added
660 directly to the dependencies for the `tags' rule.
662 Automake also generates a `ctags' rule that can be used to build
663 `vi'-style `tags' files. The variable `CTAGS' is the name of the
664 program to invoke (by default `ctags'); `CTAGSFLAGS' can be used by the
665 user to pass additional flags, and `AM_CTAGSFLAGS' can be used by the
668 Automake will also generate an `ID' rule that will run `mkid' on the
669 source. This is only supported on a directory-by-directory basis.
671 Finally, Automake also emits rules to support the GNU Global Tags
672 program (http://www.gnu.org/software/global/). The `GTAGS' rule runs
673 Global Tags and puts the result in the top build directory. The
674 variable `GTAGS_ARGS' holds arguments that are passed to `gtags'.
677 File: automake.info, Node: Suffixes, Next: Multilibs, Prev: Tags, Up: Miscellaneous
679 18.2 Handling new file extensions
680 =================================
682 It is sometimes useful to introduce a new implicit rule to handle a file
683 type that Automake does not know about.
685 For instance, suppose you had a compiler that could compile `.foo'
686 files to `.o' files. You would simply define a suffix rule for your
692 Then you could directly use a `.foo' file in a `_SOURCES' variable
693 and expect the correct results:
696 doit_SOURCES = doit.foo
698 This was the simpler and more common case. In other cases, you will
699 have to help Automake to figure out which extensions you are defining
700 your suffix rule for. This usually happens when your extension does not
701 start with a dot. Then, all you have to do is to put a list of new
702 suffixes in the `SUFFIXES' variable *before* you define your implicit
705 For instance, the following definition prevents Automake from
706 misinterpreting the `.idlC.cpp:' rule as an attempt to transform
707 `.idlC' files into `.cpp' files.
709 SUFFIXES = .idl C.cpp
713 As you may have noted, the `SUFFIXES' variable behaves like the
714 `.SUFFIXES' special target of `make'. You should not touch `.SUFFIXES'
715 yourself, but use `SUFFIXES' instead and let Automake generate the
716 suffix list for `.SUFFIXES'. Any given `SUFFIXES' go at the start of
717 the generated suffixes list, followed by Automake generated suffixes
718 not already in the list.
721 File: automake.info, Node: Multilibs, Prev: Suffixes, Up: Miscellaneous
723 18.3 Support for Multilibs
724 ==========================
726 Automake has support for an obscure feature called multilibs. A
727 "multilib" is a library that is built for multiple different ABIs at a
728 single time; each time the library is built with a different target
729 flag combination. This is only useful when the library is intended to
730 be cross-compiled, and it is almost exclusively used for compiler
733 The multilib support is still experimental. Only use it if you are
734 familiar with multilibs and can debug problems you might encounter.
737 File: automake.info, Node: Include, Next: Conditionals, Prev: Miscellaneous, Up: Top
742 Automake supports an `include' directive that can be used to include
743 other `Makefile' fragments when `automake' is run. Note that these
744 fragments are read and interpreted by `automake', not by `make'. As
745 with conditionals, `make' has no idea that `include' is in use.
747 There are two forms of `include':
749 `include $(srcdir)/file'
750 Include a fragment that is found relative to the current source
753 `include $(top_srcdir)/file'
754 Include a fragment that is found relative to the top source
757 Note that if a fragment is included inside a conditional, then the
758 condition applies to the entire contents of that fragment.
760 Makefile fragments included this way are always distributed because
761 they are needed to rebuild `Makefile.in'.
764 File: automake.info, Node: Conditionals, Next: Gnits, Prev: Include, Up: Top
769 Automake supports a simple type of conditionals.
771 These conditionals are not the same as conditionals in GNU Make.
772 Automake conditionals are checked at configure time by the `configure'
773 script, and affect the translation from `Makefile.in' to `Makefile'.
774 They are based on options passed to `configure' and on results that
775 `configure' has discovered about the host system. GNU Make
776 conditionals are checked at `make' time, and are based on variables
777 passed to the make program or defined in the `Makefile'.
779 Automake conditionals will work with any make program.
783 * Usage of Conditionals:: Declaring conditional content
784 * Limits of Conditionals:: Enclosing complete statements
787 File: automake.info, Node: Usage of Conditionals, Next: Limits of Conditionals, Up: Conditionals
789 20.1 Usage of Conditionals
790 ==========================
792 Before using a conditional, you must define it by using
793 `AM_CONDITIONAL' in the `configure.ac' file (*note Macros::).
795 -- Macro: AM_CONDITIONAL (CONDITIONAL, CONDITION)
796 The conditional name, CONDITIONAL, should be a simple string
797 starting with a letter and containing only letters, digits, and
798 underscores. It must be different from `TRUE' and `FALSE' that
799 are reserved by Automake.
801 The shell CONDITION (suitable for use in a shell `if' statement)
802 is evaluated when `configure' is run. Note that you must arrange
803 for _every_ `AM_CONDITIONAL' to be invoked every time `configure'
804 is run. If `AM_CONDITIONAL' is run conditionally (e.g., in a
805 shell `if' statement), then the result will confuse `automake'.
807 Conditionals typically depend upon options that the user provides to
808 the `configure' script. Here is an example of how to write a
809 conditional that is true if the user uses the `--enable-debug' option.
811 AC_ARG_ENABLE([debug],
812 [ --enable-debug Turn on debugging],
813 [case "${enableval}" in
816 *) AC_MSG_ERROR([bad value ${enableval} for --enable-debug]) ;;
818 AM_CONDITIONAL([DEBUG], [test x$debug = xtrue])
820 Here is an example of how to use that conditional in `Makefile.am':
827 noinst_PROGRAMS = $(DBG)
829 This trivial example could also be handled using `EXTRA_PROGRAMS'
830 (*note Conditional Programs::).
832 You may only test a single variable in an `if' statement, possibly
833 negated using `!'. The `else' statement may be omitted. Conditionals
834 may be nested to any depth. You may specify an argument to `else' in
835 which case it must be the negation of the condition used for the
836 current `if'. Similarly you may specify the condition that is closed
845 Unbalanced conditions are errors. The `if', `else', and `endif'
846 statements should not be indented, i.e., start on column one.
848 The `else' branch of the above two examples could be omitted, since
849 assigning the empty string to an otherwise undefined variable makes no
852 In order to allow access to the condition registered by
853 `AM_CONDITIONAL' inside `configure.ac', and to allow conditional
854 `AC_CONFIG_FILES', `AM_COND_IF' may be used:
856 -- Macro: AM_COND_IF (CONDITIONAL, [IF-TRUE], [IF-FALSE])
857 If CONDITIONAL is fulfilled, execute IF-TRUE, otherwise execute
858 IF-FALSE. If either branch contains `AC_CONFIG_FILES', it will
859 cause `automake' to output the rules for the respective files only
860 for the given condition.
862 `AM_COND_IF' macros may be nested when m4 quotation is used properly
863 (*note M4 Quotation: (autoconf)M4 Quotation.).
865 Here is an example of how to define a conditional config file:
867 AM_CONDITIONAL([SHELL_WRAPPER], [test "x$with_wrapper" = xtrue])
868 AM_COND_IF([SHELL_WRAPPER],
869 [AC_CONFIG_FILES([wrapper:wrapper.in])])
872 File: automake.info, Node: Limits of Conditionals, Prev: Usage of Conditionals, Up: Conditionals
874 20.2 Limits of Conditionals
875 ===========================
877 Conditionals should enclose complete statements like variables or rules
878 definitions. Automake cannot deal with conditionals used inside a
879 variable definition, for instance, and is not even able to diagnose
880 this situation. The following example would not work:
882 # This syntax is not understood by Automake
890 However the intended definition of `AM_CPPFLAGS' can be achieved with
895 AM_CPPFLAGS = -DFEATURE_A $(DEBUGFLAGS) -DFEATURE_B
899 AM_CPPFLAGS = -DFEATURE_A
901 AM_CPPFLAGS += -DDEBUG
903 AM_CPPFLAGS += -DFEATURE_B
905 More details and examples of conditionals are described alongside
906 various Automake features in this manual (*note Conditional
907 Subdirectories::, *note Conditional Sources::, *note Conditional
908 Programs::, *note Conditional Libtool Libraries::, *note Conditional
912 File: automake.info, Node: Gnits, Next: Cygnus, Prev: Conditionals, Up: Top
914 21 The effect of `--gnu' and `--gnits'
915 **************************************
917 The `--gnu' option (or `gnu' in the `AUTOMAKE_OPTIONS' variable) causes
918 `automake' to check the following:
920 * The files `INSTALL', `NEWS', `README', `AUTHORS', and `ChangeLog',
921 plus one of `COPYING.LIB', `COPYING.LESSER' or `COPYING', are
922 required at the topmost directory of the package.
924 If the `--add-missing' option is given, `automake' will add a
925 generic version of the `INSTALL' file as well as the `COPYING'
926 file containing the text of the current version of the GNU General
927 Public License existing at the time of this Automake release
928 (version 3 as this is written,
929 `http://www.gnu.org/copyleft/gpl.html'). However, an existing
930 `COPYING' file will never be overwritten by `automake'.
932 * The options `no-installman' and `no-installinfo' are prohibited.
934 Note that this option will be extended in the future to do even more
935 checking; it is advisable to be familiar with the precise requirements
936 of the GNU standards. Also, `--gnu' can require certain non-standard
937 GNU programs to exist for use by various maintainer-only rules; for
938 instance, in the future `pathchk' might be required for `make dist'.
940 The `--gnits' option does everything that `--gnu' does, and checks
941 the following as well:
943 * `make installcheck' will check to make sure that the `--help' and
944 `--version' really print a usage message and a version string,
945 respectively. This is the `std-options' option (*note Options::).
947 * `make dist' will check to make sure the `NEWS' file has been
948 updated to the current version.
950 * `VERSION' is checked to make sure its format complies with Gnits
953 * If `VERSION' indicates that this is an alpha release, and the file
954 `README-alpha' appears in the topmost directory of a package, then
955 it is included in the distribution. This is done in `--gnits'
956 mode, and no other, because this mode is the only one where version
957 number formats are constrained, and hence the only mode where
958 Automake can automatically determine whether `README-alpha' should
961 * The file `THANKS' is required.
964 File: automake.info, Node: Cygnus, Next: Not Enough, Prev: Gnits, Up: Top
966 22 The effect of `--cygnus'
967 ***************************
969 Some packages, notably GNU GCC and GNU gdb, have a build environment
970 originally written at Cygnus Support (subsequently renamed Cygnus
971 Solutions, and then later purchased by Red Hat). Packages with this
972 ancestry are sometimes referred to as "Cygnus" trees.
974 A Cygnus tree has slightly different rules for how a `Makefile.in'
975 is to be constructed. Passing `--cygnus' to `automake' will cause any
976 generated `Makefile.in' to comply with Cygnus rules.
978 Here are the precise effects of `--cygnus':
980 * Info files are always created in the build directory, and not in
981 the source directory.
983 * `texinfo.tex' is not required if a Texinfo source file is
984 specified. The assumption is that the file will be supplied, but
985 in a place that Automake cannot find. This assumption is an
986 artifact of how Cygnus packages are typically bundled.
988 * `make dist' is not supported, and the rules for it are not
989 generated. Cygnus-style trees use their own distribution
992 * Certain tools will be searched for in the build tree as well as in
993 the user's `PATH'. These tools are `runtest', `expect',
994 `makeinfo' and `texi2dvi'.
996 * `--foreign' is implied.
998 * The options `no-installinfo' and `no-dependencies' are implied.
1000 * The macros `AM_MAINTAINER_MODE' and `AM_CYGWIN32' are required.
1002 * The `check' target doesn't depend on `all'.
1004 GNU maintainers are advised to use `gnu' strictness in preference to
1005 the special Cygnus mode. Some day, perhaps, the differences between
1006 Cygnus trees and GNU trees will disappear (for instance, as GCC is made
1007 more standards compliant). At that time the special Cygnus mode will be
1011 File: automake.info, Node: Not Enough, Next: Distributing, Prev: Cygnus, Up: Top
1013 23 When Automake Isn't Enough
1014 *****************************
1016 In some situations, where Automake is not up to one task, one has to
1017 resort to handwritten rules or even handwritten `Makefile's.
1021 * Extending:: Adding new rules or overriding existing ones.
1022 * Third-Party Makefiles:: Integrating Non-Automake `Makefile's.
1025 File: automake.info, Node: Extending, Next: Third-Party Makefiles, Up: Not Enough
1027 23.1 Extending Automake Rules
1028 =============================
1030 With some minor exceptions (for example `_PROGRAMS' variables, `TESTS',
1031 or `XFAIL_TESTS') being rewritten to append `$(EXEEXT)'), the contents
1032 of a `Makefile.am' is copied to `Makefile.in' verbatim.
1034 These copying semantics mean that many problems can be worked around
1035 by simply adding some `make' variables and rules to `Makefile.am'.
1036 Automake will ignore these additions.
1038 Since a `Makefile.in' is built from data gathered from three
1039 different places (`Makefile.am', `configure.ac', and `automake'
1040 itself), it is possible to have conflicting definitions of rules or
1041 variables. When building `Makefile.in' the following priorities are
1042 respected by `automake' to ensure the user always has the last word:
1044 * User defined variables in `Makefile.am' have priority over
1045 variables `AC_SUBST'ed from `configure.ac', and `AC_SUBST'ed
1046 variables have priority over `automake'-defined variables.
1048 * As far as rules are concerned, a user-defined rule overrides any
1049 `automake'-defined rule for the same target.
1051 These overriding semantics make it possible to fine tune some default
1052 settings of Automake, or replace some of its rules. Overriding
1053 Automake rules is often inadvisable, particularly in the topmost
1054 directory of a package with subdirectories. The `-Woverride' option
1055 (*note Invoking Automake::) comes in handy to catch overridden
1058 Note that Automake does not make any distinction between rules with
1059 commands and rules that only specify dependencies. So it is not
1060 possible to append new dependencies to an `automake'-defined target
1061 without redefining the entire rule.
1063 However, various useful targets have a `-local' version you can
1064 specify in your `Makefile.am'. Automake will supplement the standard
1065 target with these user-supplied targets.
1067 The targets that support a local version are `all', `info', `dvi',
1068 `ps', `pdf', `html', `check', `install-data', `install-dvi',
1069 `install-exec', `install-html', `install-info', `install-pdf',
1070 `install-ps', `uninstall', `installdirs', `installcheck' and the
1071 various `clean' targets (`mostlyclean', `clean', `distclean', and
1072 `maintainer-clean').
1074 Note that there are no `uninstall-exec-local' or
1075 `uninstall-data-local' targets; just use `uninstall-local'. It doesn't
1076 make sense to uninstall just data or just executables.
1078 For instance, here is one way to erase a subdirectory during `make
1079 clean' (*note Clean::).
1084 You may be tempted to use `install-data-local' to install a file to
1085 some hard-coded location, but you should avoid this (*note Hard-Coded
1088 With the `-local' targets, there is no particular guarantee of
1089 execution order; typically, they are run early, but with parallel make,
1090 there is no way to be sure of that.
1092 In contrast, some rules also have a way to run another rule, called a
1093 "hook"; hooks are always executed after the main rule's work is done.
1094 The hook is named after the principal target, with `-hook' appended.
1095 The targets allowing hooks are `install-data', `install-exec',
1096 `uninstall', `dist', and `distcheck'.
1098 For instance, here is how to create a hard link to an installed
1102 ln $(DESTDIR)$(bindir)/program$(EXEEXT) \
1103 $(DESTDIR)$(bindir)/proglink$(EXEEXT)
1105 Although cheaper and more portable than symbolic links, hard links
1106 will not work everywhere (for instance, OS/2 does not have `ln').
1107 Ideally you should fall back to `cp -p' when `ln' does not work. An
1108 easy way, if symbolic links are acceptable to you, is to add
1109 `AC_PROG_LN_S' to `configure.ac' (*note Particular Program Checks:
1110 (autoconf)Particular Programs.) and use `$(LN_S)' in `Makefile.am'.
1112 For instance, here is how you could install a versioned copy of a
1113 program using `$(LN_S)':
1116 cd $(DESTDIR)$(bindir) && \
1117 mv -f prog$(EXEEXT) prog-$(VERSION)$(EXEEXT) && \
1118 $(LN_S) prog-$(VERSION)$(EXEEXT) prog$(EXEEXT)
1120 Note that we rename the program so that a new version will erase the
1121 symbolic link, not the real binary. Also we `cd' into the destination
1122 directory in order to create relative links.
1124 When writing `install-exec-hook' or `install-data-hook', please bear
1125 in mind that the exec/data distinction is based on the installation
1126 directory, not on the primary used (*note The Two Parts of Install::).
1127 So a `foo_SCRIPTS' will be installed by `install-data', and a
1128 `barexec_SCRIPTS' will be installed by `install-exec'. You should
1129 define your hooks consequently.
1132 File: automake.info, Node: Third-Party Makefiles, Prev: Extending, Up: Not Enough
1134 23.2 Third-Party `Makefile's
1135 ============================
1137 In most projects all `Makefile's are generated by Automake. In some
1138 cases, however, projects need to embed subdirectories with handwritten
1139 `Makefile's. For instance, one subdirectory could be a third-party
1140 project with its own build system, not using Automake.
1142 It is possible to list arbitrary directories in `SUBDIRS' or
1143 `DIST_SUBDIRS' provided each of these directories has a `Makefile' that
1144 recognizes all the following recursive targets.
1146 When a user runs one of these targets, that target is run recursively
1147 in all subdirectories. This is why it is important that even
1148 third-party `Makefile's support them.
1151 Compile the entire package. This is the default target in
1152 Automake-generated `Makefile's, but it does not need to be the
1153 default in third-party `Makefile's.
1156 Copy files to distribute into `$(distdir)', before a tarball is
1157 constructed. Of course this target is not required if the
1158 `no-dist' option (*note Options::) is used.
1160 The variables `$(top_distdir)' and `$(distdir)' (*note The dist
1161 Hook::) will be passed from the outer package to the subpackage
1162 when the `distdir' target is invoked. These two variables have
1163 been adjusted for the directory that is being recursed into, so
1164 they are ready to use.
1170 Install or uninstall files (*note Install::).
1177 Install only some specific documentation format (*note Texinfo::).
1180 Create install directories, but do not install any files.
1184 Check the package (*note Tests::).
1190 Cleaning rules (*note Clean::).
1197 Build the documentation in various formats (*note Texinfo::).
1201 Build `TAGS' and `CTAGS' (*note Tags::).
1203 If you have ever used Gettext in a project, this is a good example of
1204 how third-party `Makefile's can be used with Automake. The `Makefile's
1205 `gettextize' puts in the `po/' and `intl/' directories are handwritten
1206 `Makefile's that implement all these targets. That way they can be
1207 added to `SUBDIRS' in Automake packages.
1209 Directories that are only listed in `DIST_SUBDIRS' but not in
1210 `SUBDIRS' need only the `distclean', `maintainer-clean', and `distdir'
1211 rules (*note Conditional Subdirectories::).
1213 Usually, many of these rules are irrelevant to the third-party
1214 subproject, but they are required for the whole package to work. It's
1215 OK to have a rule that does nothing, so if you are integrating a
1216 third-party project with no documentation or tag support, you could
1217 simply augment its `Makefile' as follows:
1219 EMPTY_AUTOMAKE_TARGETS = dvi pdf ps info html tags ctags
1220 .PHONY: $(EMPTY_AUTOMAKE_TARGETS)
1221 $(EMPTY_AUTOMAKE_TARGETS):
1223 Another aspect of integrating third-party build systems is whether
1224 they support VPATH builds (*note VPATH Builds::). Obviously if the
1225 subpackage does not support VPATH builds the whole package will not
1226 support VPATH builds. This in turns means that `make distcheck' will
1227 not work, because it relies on VPATH builds. Some people can live
1228 without this (actually, many Automake users have never heard of `make
1229 distcheck'). Other people may prefer to revamp the existing
1230 `Makefile's to support VPATH. Doing so does not necessarily require
1231 Automake, only Autoconf is needed (*note Build Directories:
1232 (autoconf)Build Directories.). The necessary substitutions:
1233 `@srcdir@', `@top_srcdir@', and `@top_builddir@' are defined by
1234 `configure' when it processes a `Makefile' (*note Preset Output
1235 Variables: (autoconf)Preset Output Variables.), they are not computed
1236 by the Makefile like the aforementioned `$(distdir)' and
1237 `$(top_distdir)' variables.
1239 It is sometimes inconvenient to modify a third-party `Makefile' to
1240 introduce the above required targets. For instance, one may want to
1241 keep the third-party sources untouched to ease upgrades to new versions.
1243 Here are two other ideas. If GNU make is assumed, one possibility is
1244 to add to that subdirectory a `GNUmakefile' that defines the required
1245 targets and includes the third-party `Makefile'. For this to work in
1246 VPATH builds, `GNUmakefile' must lie in the build directory; the
1247 easiest way to do this is to write a `GNUmakefile.in' instead, and have
1248 it processed with `AC_CONFIG_FILES' from the outer package. For
1249 example if we assume `Makefile' defines all targets except the
1250 documentation targets, and that the `check' target is actually called
1251 `test', we could write `GNUmakefile' (or `GNUmakefile.in') like this:
1253 # First, include the real Makefile
1255 # Then, define the other targets needed by Automake Makefiles.
1256 .PHONY: dvi pdf ps info html check
1257 dvi pdf ps info html:
1260 A similar idea that does not use `include' is to write a proxy
1261 `Makefile' that dispatches rules to the real `Makefile', either with
1262 `$(MAKE) -f Makefile.real $(AM_MAKEFLAGS) target' (if it's OK to rename
1263 the original `Makefile') or with `cd subdir && $(MAKE) $(AM_MAKEFLAGS)
1264 target' (if it's OK to store the subdirectory project one directory
1265 deeper). The good news is that this proxy `Makefile' can be generated
1266 with Automake. All we need are `-local' targets (*note Extending::)
1267 that perform the dispatch. Of course the other Automake features are
1268 available, so you could decide to let Automake perform distribution or
1269 installation. Here is a possible `Makefile.am':
1272 cd subdir && $(MAKE) $(AM_MAKEFLAGS) all
1274 cd subdir && $(MAKE) $(AM_MAKEFLAGS) test
1276 cd subdir && $(MAKE) $(AM_MAKEFLAGS) clean
1278 # Assuming the package knows how to install itself
1280 cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-data
1282 cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-exec
1284 cd subdir && $(MAKE) $(AM_MAKEFLAGS) uninstall
1286 # Distribute files from here.
1287 EXTRA_DIST = subdir/Makefile subdir/program.c ...
1289 Pushing this idea to the extreme, it is also possible to ignore the
1290 subproject build system and build everything from this proxy
1291 `Makefile.am'. This might sound very sensible if you need VPATH builds
1292 but the subproject does not support them.
1295 File: automake.info, Node: Distributing, Next: API Versioning, Prev: Not Enough, Up: Top
1297 24 Distributing `Makefile.in's
1298 ******************************
1300 Automake places no restrictions on the distribution of the resulting
1301 `Makefile.in's. We still encourage software authors to distribute
1302 their work under terms like those of the GPL, but doing so is not
1303 required to use Automake.
1305 Some of the files that can be automatically installed via the
1306 `--add-missing' switch do fall under the GPL. However, these also have
1307 a special exception allowing you to distribute them with your package,
1308 regardless of the licensing you choose.
1311 File: automake.info, Node: API Versioning, Next: Upgrading, Prev: Distributing, Up: Top
1313 25 Automake API Versioning
1314 **************************
1316 New Automake releases usually include bug fixes and new features.
1317 Unfortunately they may also introduce new bugs and incompatibilities.
1318 This makes four reasons why a package may require a particular Automake
1321 Things get worse when maintaining a large tree of packages, each one
1322 requiring a different version of Automake. In the past, this meant that
1323 any developer (and sometimes users) had to install several versions of
1324 Automake in different places, and switch `$PATH' appropriately for each
1327 Starting with version 1.6, Automake installs versioned binaries.
1328 This means you can install several versions of Automake in the same
1329 `$prefix', and can select an arbitrary Automake version by running
1330 `automake-1.6' or `automake-1.7' without juggling with `$PATH'.
1331 Furthermore, `Makefile''s generated by Automake 1.6 will use
1332 `automake-1.6' explicitly in their rebuild rules.
1334 The number `1.6' in `automake-1.6' is Automake's API version, not
1335 Automake's version. If a bug fix release is made, for instance
1336 Automake 1.6.1, the API version will remain 1.6. This means that a
1337 package that works with Automake 1.6 should also work with 1.6.1; after
1338 all, this is what people expect from bug fix releases.
1340 If your package relies on a feature or a bug fix introduced in a
1341 release, you can pass this version as an option to Automake to ensure
1342 older releases will not be used. For instance, use this in your
1345 AM_INIT_AUTOMAKE([1.6.1]) dnl Require Automake 1.6.1 or better.
1346 or, in a particular `Makefile.am':
1348 AUTOMAKE_OPTIONS = 1.6.1 # Require Automake 1.6.1 or better.
1349 Automake will print an error message if its version is older than
1350 the requested version.
1355 Automake's programming interface is not easy to define. Basically it
1356 should include at least all *documented* variables and targets that a
1357 `Makefile.am' author can use, any behavior associated with them (e.g.,
1358 the places where `-hook''s are run), the command line interface of
1359 `automake' and `aclocal', ...
1361 What is not in the API
1362 ======================
1364 Every undocumented variable, target, or command line option, is not part
1365 of the API. You should avoid using them, as they could change from one
1366 version to the other (even in bug fix releases, if this helps to fix a
1369 If it turns out you need to use such an undocumented feature, contact
1370 <automake@gnu.org> and try to get it documented and exercised by the
1374 File: automake.info, Node: Upgrading, Next: FAQ, Prev: API Versioning, Up: Top
1376 26 Upgrading a Package to a Newer Automake Version
1377 **************************************************
1379 Automake maintains three kind of files in a package.
1385 * auxiliary tools like `install-sh' or `py-compile'
1387 `aclocal.m4' is generated by `aclocal' and contains some
1388 Automake-supplied M4 macros. Auxiliary tools are installed by
1389 `automake --add-missing' when needed. `Makefile.in's are built from
1390 `Makefile.am' by `automake', and rely on the definitions of the M4
1391 macros put in `aclocal.m4' as well as the behavior of the auxiliary
1394 Because all these files are closely related, it is important to
1395 regenerate all of them when upgrading to a newer Automake release. The
1396 usual way to do that is
1398 aclocal # with any option needed (such a -I m4)
1400 automake --add-missing --force-missing
1402 or more conveniently:
1406 The use of `--force-missing' ensures that auxiliary tools will be
1407 overridden by new versions (*note Invoking Automake::).
1409 It is important to regenerate all these files each time Automake is
1410 upgraded, even between bug fixes releases. For instance, it is not
1411 unusual for a bug fix to involve changes to both the rules generated in
1412 `Makefile.in' and the supporting M4 macros copied to `aclocal.m4'.
1414 Presently `automake' is able to diagnose situations where
1415 `aclocal.m4' has been generated with another version of `aclocal'.
1416 However it never checks whether auxiliary scripts are up-to-date. In
1417 other words, `automake' will tell you when `aclocal' needs to be rerun,
1418 but it will never diagnose a missing `--force-missing'.
1420 Before upgrading to a new major release, it is a good idea to read
1421 the file `NEWS'. This file lists all changes between releases: new
1422 features, obsolete constructs, known incompatibilities, and workarounds.
1425 File: automake.info, Node: FAQ, Next: History, Prev: Upgrading, Up: Top
1427 27 Frequently Asked Questions about Automake
1428 ********************************************
1430 This chapter covers some questions that often come up on the mailing
1435 * CVS:: CVS and generated files
1436 * maintainer-mode:: missing and AM_MAINTAINER_MODE
1437 * Wildcards:: Why doesn't Automake support wildcards?
1438 * Limitations on File Names:: Limitations on source and installed file names
1439 * distcleancheck:: Files left in build directory after distclean
1440 * Flag Variables Ordering:: CFLAGS vs. AM_CFLAGS vs. mumble_CFLAGS
1441 * Renamed Objects:: Why are object files sometimes renamed?
1442 * Per-Object Flags:: How to simulate per-object flags?
1443 * Multiple Outputs:: Writing rules for tools with many output files
1444 * Hard-Coded Install Paths:: Installing to hard-coded locations
1445 * Debugging Make Rules:: Strategies when things don't work as expected
1448 File: automake.info, Node: CVS, Next: maintainer-mode, Up: FAQ
1450 27.1 CVS and generated files
1451 ============================
1453 Background: distributed generated Files
1454 ---------------------------------------
1456 Packages made with Autoconf and Automake ship with some generated files
1457 like `configure' or `Makefile.in'. These files were generated on the
1458 developer's host and are distributed so that end-users do not have to
1459 install the maintainer tools required to rebuild them. Other generated
1460 files like Lex scanners, Yacc parsers, or Info documentation, are
1461 usually distributed on similar grounds.
1463 Automake outputs rules in `Makefile's to rebuild these files. For
1464 instance, `make' will run `autoconf' to rebuild `configure' whenever
1465 `configure.ac' is changed. This makes development safer by ensuring a
1466 `configure' is never out-of-date with respect to `configure.ac'.
1468 As generated files shipped in packages are up-to-date, and because
1469 `tar' preserves times-tamps, these rebuild rules are not triggered when
1470 a user unpacks and builds a package.
1472 Background: CVS and Timestamps
1473 ------------------------------
1475 Unless you use CVS keywords (in which case files must be updated at
1476 commit time), CVS preserves timestamp during `cvs commit' and `cvs
1477 import -d' operations.
1479 When you check out a file using `cvs checkout' its timestamp is set
1480 to that of the revision that is being checked out.
1482 However, during `cvs update', files will have the date of the
1483 update, not the original timestamp of this revision. This is meant to
1484 make sure that `make' notices sources files have been updated.
1486 This timestamp shift is troublesome when both sources and generated
1487 files are kept under CVS. Because CVS processes files in lexical
1488 order, `configure.ac' will appear newer than `configure' after a `cvs
1489 update' that updates both files, even if `configure' was newer than
1490 `configure.ac' when it was checked in. Calling `make' will then
1491 trigger a spurious rebuild of `configure'.
1493 Living with CVS in Autoconfiscated Projects
1494 -------------------------------------------
1496 There are basically two clans amongst maintainers: those who keep all
1497 distributed files under CVS, including generated files, and those who
1498 keep generated files _out_ of CVS.
1503 * The CVS repository contains all distributed files so you know
1504 exactly what is distributed, and you can checkout any prior
1507 * Maintainers can see how generated files evolve (for instance, you
1508 can see what happens to your `Makefile.in's when you upgrade
1509 Automake and make sure they look OK).
1511 * Users do not need the autotools to build a checkout of the
1512 project, it works just like a released tarball.
1514 * If users use `cvs update' to update their copy, instead of `cvs
1515 checkout' to fetch a fresh one, timestamps will be inaccurate.
1516 Some rebuild rules will be triggered and attempt to run developer
1517 tools such as `autoconf' or `automake'.
1519 Actually, calls to such tools are all wrapped into a call to the
1520 `missing' script discussed later (*note maintainer-mode::).
1521 `missing' will take care of fixing the timestamps when these tools
1522 are not installed, so that the build can continue.
1524 * In distributed development, developers are likely to have different
1525 version of the maintainer tools installed. In this case rebuilds
1526 triggered by timestamp lossage will lead to spurious changes to
1527 generated files. There are several solutions to this:
1529 * All developers should use the same versions, so that the
1530 rebuilt files are identical to files in CVS. (This starts to
1531 be difficult when each project you work on uses different
1534 * Or people use a script to fix the timestamp after a checkout
1535 (the GCC folks have such a script).
1537 * Or `configure.ac' uses `AM_MAINTAINER_MODE', which will
1538 disable all these rebuild rules by default. This is further
1539 discussed in *note maintainer-mode::.
1541 * Although we focused on spurious rebuilds, the converse can also
1542 happen. CVS's timestamp handling can also let you think an
1543 out-of-date file is up-to-date.
1545 For instance, suppose a developer has modified `Makefile.am' and
1546 has rebuilt `Makefile.in'. He then decides to do a last-minute
1547 change to `Makefile.am' right before checking in both files
1548 (without rebuilding `Makefile.in' to account for the change).
1550 This last change to `Makefile.am' makes the copy of `Makefile.in'
1551 out-of-date. Since CVS processes files alphabetically, when
1552 another developer `cvs update's his or her tree, `Makefile.in'
1553 will happen to be newer than `Makefile.am'. This other developer
1554 will not see that `Makefile.in' is out-of-date.
1557 Generated Files out of CVS
1558 ..........................
1560 One way to get CVS and `make' working peacefully is to never store
1561 generated files in CVS, i.e., do not CVS-control files that are
1562 `Makefile' targets (also called _derived_ files).
1564 This way developers are not annoyed by changes to generated files.
1565 It does not matter if they all have different versions (assuming they
1566 are compatible, of course). And finally, timestamps are not lost,
1567 changes to sources files can't be missed as in the
1568 `Makefile.am'/`Makefile.in' example discussed earlier.
1570 The drawback is that the CVS repository is not an exact copy of what
1571 is distributed and that users now need to install various development
1572 tools (maybe even specific versions) before they can build a checkout.
1573 But, after all, CVS's job is versioning, not distribution.
1575 Allowing developers to use different versions of their tools can also
1576 hide bugs during distributed development. Indeed, developers will be
1577 using (hence testing) their own generated files, instead of the
1578 generated files that will be released actually. The developer who
1579 prepares the tarball might be using a version of the tool that produces
1580 bogus output (for instance a non-portable C file), something other
1581 developers could have noticed if they weren't using their own versions
1587 Another class of files not discussed here (because they do not cause
1588 timestamp issues) are files that are shipped with a package, but
1589 maintained elsewhere. For instance, tools like `gettextize' and
1590 `autopoint' (from Gettext) or `libtoolize' (from Libtool), will install
1591 or update files in your package.
1593 These files, whether they are kept under CVS or not, raise similar
1594 concerns about version mismatch between developers' tools. The Gettext
1595 manual has a section about this, see *note CVS Issues: (gettext)CVS
1599 File: automake.info, Node: maintainer-mode, Next: Wildcards, Prev: CVS, Up: FAQ
1601 27.2 `missing' and `AM_MAINTAINER_MODE'
1602 =======================================
1607 The `missing' script is a wrapper around several maintainer tools,
1608 designed to warn users if a maintainer tool is required but missing.
1609 Typical maintainer tools are `autoconf', `automake', `bison', etc.
1610 Because file generated by these tools are shipped with the other
1611 sources of a package, these tools shouldn't be required during a user
1612 build and they are not checked for in `configure'.
1614 However, if for some reason a rebuild rule is triggered and involves
1615 a missing tool, `missing' will notice it and warn the user. Besides
1616 the warning, when a tool is missing, `missing' will attempt to fix
1617 timestamps in a way that allows the build to continue. For instance,
1618 `missing' will touch `configure' if `autoconf' is not installed. When
1619 all distributed files are kept under CVS, this feature of `missing'
1620 allows a user _with no maintainer tools_ to build a package off CVS,
1621 bypassing any timestamp inconsistency implied by `cvs update'.
1623 If the required tool is installed, `missing' will run it and won't
1624 attempt to continue after failures. This is correct during
1625 development: developers love fixing failures. However, users with
1626 wrong versions of maintainer tools may get an error when the rebuild
1627 rule is spuriously triggered, halting the build. This failure to let
1628 the build continue is one of the arguments of the `AM_MAINTAINER_MODE'
1631 `AM_MAINTAINER_MODE'
1632 --------------------
1634 `AM_MAINTAINER_MODE' allows you to choose whether the so called
1635 "rebuild rules" should be enabled or disabled. With
1636 `AM_MAINTAINER_MODE([enable])', they are enabled by default, otherwise
1637 they are disabled by default. In the latter case, if you have
1638 `AM_MAINTAINER_MODE' in `configure.ac', and run `./configure && make',
1639 then `make' will *never* attempt to rebuild `configure',
1640 `Makefile.in's, Lex or Yacc outputs, etc. I.e., this disables build
1641 rules for files that are usually distributed and that users should
1642 normally not have to update.
1644 The user can override the default setting by passing either
1645 `--enable-maintainer-mode' or `--disable-maintainer-mode' to
1648 People use `AM_MAINTAINER_MODE' either because they do not want their
1649 users (or themselves) annoyed by timestamps lossage (*note CVS::), or
1650 because they simply can't stand the rebuild rules and prefer running
1651 maintainer tools explicitly.
1653 `AM_MAINTAINER_MODE' also allows you to disable some custom build
1654 rules conditionally. Some developers use this feature to disable rules
1655 that need exotic tools that users may not have available.
1657 Several years ago Franc,ois Pinard pointed out several arguments
1658 against this `AM_MAINTAINER_MODE' macro. Most of them relate to
1659 insecurity. By removing dependencies you get non-dependable builds:
1660 changes to sources files can have no effect on generated files and this
1661 can be very confusing when unnoticed. He adds that security shouldn't
1662 be reserved to maintainers (what `--enable-maintainer-mode' suggests),
1663 on the contrary. If one user has to modify a `Makefile.am', then
1664 either `Makefile.in' should be updated or a warning should be output
1665 (this is what Automake uses `missing' for) but the last thing you want
1666 is that nothing happens and the user doesn't notice it (this is what
1667 happens when rebuild rules are disabled by `AM_MAINTAINER_MODE').
1669 Jim Meyering, the inventor of the `AM_MAINTAINER_MODE' macro was
1670 swayed by Franc,ois's arguments, and got rid of `AM_MAINTAINER_MODE' in
1671 all of his packages.
1673 Still many people continue to use `AM_MAINTAINER_MODE', because it
1674 helps them working on projects where all files are kept under CVS, and
1675 because `missing' isn't enough if you have the wrong version of the
1679 File: automake.info, Node: Wildcards, Next: Limitations on File Names, Prev: maintainer-mode, Up: FAQ
1681 27.3 Why doesn't Automake support wildcards?
1682 ============================================
1684 Developers are lazy. They would often like to use wildcards in
1685 `Makefile.am's, so that they would not need to remember to update
1686 `Makefile.am's every time they add, delete, or rename a file.
1688 There are several objections to this:
1689 * When using CVS (or similar) developers need to remember they have
1690 to run `cvs add' or `cvs rm' anyway. Updating `Makefile.am'
1691 accordingly quickly becomes a reflex.
1693 Conversely, if your application doesn't compile because you forgot
1694 to add a file in `Makefile.am', it will help you remember to `cvs
1697 * Using wildcards makes it easy to distribute files by mistake. For
1698 instance, some code a developer is experimenting with (a test case,
1699 say) that should not be part of the distribution.
1701 * Using wildcards it's easy to omit some files by mistake. For
1702 instance, one developer creates a new file, uses it in many places,
1703 but forgets to commit it. Another developer then checks out the
1704 incomplete project and is able to run `make dist' successfully,
1705 even though a file is missing. By listing files, `make dist'
1708 * Finally, it's really hard to _forget_ to add a file to
1709 `Makefile.am': files that are not listed in `Makefile.am' are not
1710 compiled or installed, so you can't even test them.
1712 Still, these are philosophical objections, and as such you may
1713 disagree, or find enough value in wildcards to dismiss all of them.
1714 Before you start writing a patch against Automake to teach it about
1715 wildcards, let's see the main technical issue: portability.
1717 Although `$(wildcard ...)' works with GNU `make', it is not portable
1718 to other `make' implementations.
1720 The only way Automake could support `$(wildcard ...)' is by
1721 expending `$(wildcard ...)' when `automake' is run. The resulting
1722 `Makefile.in's would be portable since they would list all files and
1723 not use `$(wildcard ...)'. However that means developers would need to
1724 remember to run `automake' each time they add, delete, or rename files.
1726 Compared to editing `Makefile.am', this is a very small gain. Sure,
1727 it's easier and faster to type `automake; make' than to type `emacs
1728 Makefile.am; make'. But nobody bothered enough to write a patch to add
1729 support for this syntax. Some people use scripts to generate file
1730 lists in `Makefile.am' or in separate `Makefile' fragments.
1732 Even if you don't care about portability, and are tempted to use
1733 `$(wildcard ...)' anyway because you target only GNU Make, you should
1734 know there are many places where Automake needs to know exactly which
1735 files should be processed. As Automake doesn't know how to expand
1736 `$(wildcard ...)', you cannot use it in these places. `$(wildcard
1737 ...)' is a black box comparable to `AC_SUBST'ed variables as far
1738 Automake is concerned.
1740 You can get warnings about `$(wildcard ...') constructs using the
1741 `-Wportability' flag.
1744 File: automake.info, Node: Limitations on File Names, Next: distcleancheck, Prev: Wildcards, Up: FAQ
1746 27.4 Limitations on File Names
1747 ==============================
1749 Automake attempts to support all kinds of file names, even those that
1750 contain unusual characters or are unusually long. However, some
1751 limitations are imposed by the underlying operating system and tools.
1753 Most operating systems prohibit the use of the null byte in file
1754 names, and reserve `/' as a directory separator. Also, they require
1755 that file names are properly encoded for the user's locale. Automake
1756 is subject to these limits.
1758 Portable packages should limit themselves to POSIX file names.
1759 These can contain ASCII letters and digits, `_', `.', and `-'. File
1760 names consist of components separated by `/'. File name components
1761 cannot begin with `-'.
1763 Portable POSIX file names cannot contain components that exceed a
1764 14-byte limit, but nowadays it's normally safe to assume the
1765 more-generous XOPEN limit of 255 bytes. POSIX limits file names to 255
1766 bytes (XOPEN allows 1023 bytes), but you may want to limit a source
1767 tarball to file names of 99 bytes to avoid interoperability problems
1768 with old versions of `tar'.
1770 If you depart from these rules (e.g., by using non-ASCII characters
1771 in file names, or by using lengthy file names), your installers may
1772 have problems for reasons unrelated to Automake. However, if this does
1773 not concern you, you should know about the limitations imposed by
1774 Automake itself. These limitations are undesirable, but some of them
1775 seem to be inherent to underlying tools like Autoconf, Make, M4, and
1776 the shell. They fall into three categories: install directories, build
1777 directories, and file names.
1779 The following characters:
1783 should not appear in the names of install directories. For example,
1784 the operand of `configure''s `--prefix' option should not contain these
1787 Build directories suffer the same limitations as install directories,
1788 and in addition should not contain the following characters:
1792 For example, the full name of the directory containing the source
1793 files should not contain these characters.
1795 Source and installation file names like `main.c' are limited even
1796 further: they should conform to the POSIX/XOPEN rules described above.
1797 In addition, if you plan to port to non-POSIX environments, you should
1798 avoid file names that differ only in case (e.g., `makefile' and
1799 `Makefile'). Nowadays it is no longer worth worrying about the 8.3
1800 limits of DOS file systems.
1803 File: automake.info, Node: distcleancheck, Next: Flag Variables Ordering, Prev: Limitations on File Names, Up: FAQ
1805 27.5 Files left in build directory after distclean
1806 ==================================================
1808 This is a diagnostic you might encounter while running `make distcheck'.
1810 As explained in *note Checking the Distribution::, `make distcheck'
1811 attempts to build and check your package for errors like this one.
1813 `make distcheck' will perform a `VPATH' build of your package (*note
1814 VPATH Builds::), and then call `make distclean'. Files left in the
1815 build directory after `make distclean' has run are listed after this
1818 This diagnostic really covers two kinds of errors:
1820 * files that are forgotten by distclean;
1822 * distributed files that are erroneously rebuilt.
1824 The former left-over files are not distributed, so the fix is to mark
1825 them for cleaning (*note Clean::), this is obvious and doesn't deserve
1828 The latter bug is not always easy to understand and fix, so let's
1829 proceed with an example. Suppose our package contains a program for
1830 which we want to build a man page using `help2man'. GNU `help2man'
1831 produces simple manual pages from the `--help' and `--version' output
1832 of other commands (*note Overview: (help2man)Top.). Because we don't
1833 want to force our users to install `help2man', we decide to distribute
1834 the generated man page using the following setup.
1836 # This Makefile.am is bogus.
1839 dist_man_MANS = foo.1
1842 help2man --output=foo.1 ./foo$(EXEEXT)
1844 This will effectively distribute the man page. However, `make
1845 distcheck' will fail with:
1847 ERROR: files left in build directory after distclean:
1850 Why was `foo.1' rebuilt? Because although distributed, `foo.1'
1851 depends on a non-distributed built file: `foo$(EXEEXT)'.
1852 `foo$(EXEEXT)' is built by the user, so it will always appear to be
1853 newer than the distributed `foo.1'.
1855 `make distcheck' caught an inconsistency in our package. Our intent
1856 was to distribute `foo.1' so users do not need to install `help2man',
1857 however since this rule causes this file to be always rebuilt, users
1858 _do_ need `help2man'. Either we should ensure that `foo.1' is not
1859 rebuilt by users, or there is no point in distributing `foo.1'.
1861 More generally, the rule is that distributed files should never
1862 depend on non-distributed built files. If you distribute something
1863 generated, distribute its sources.
1865 One way to fix the above example, while still distributing `foo.1'
1866 is to not depend on `foo$(EXEEXT)'. For instance, assuming `foo
1867 --version' and `foo --help' do not change unless `foo.c' or
1868 `configure.ac' change, we could write the following `Makefile.am':
1872 dist_man_MANS = foo.1
1874 foo.1: foo.c $(top_srcdir)/configure.ac
1875 $(MAKE) $(AM_MAKEFLAGS) foo$(EXEEXT)
1876 help2man --output=foo.1 ./foo$(EXEEXT)
1878 This way, `foo.1' will not get rebuilt every time `foo$(EXEEXT)'
1879 changes. The `make' call makes sure `foo$(EXEEXT)' is up-to-date
1880 before `help2man'. Another way to ensure this would be to use separate
1881 directories for binaries and man pages, and set `SUBDIRS' so that
1882 binaries are built before man pages.
1884 We could also decide not to distribute `foo.1'. In this case it's
1885 fine to have `foo.1' dependent upon `foo$(EXEEXT)', since both will
1886 have to be rebuilt. However it would be impossible to build the
1887 package in a cross-compilation, because building `foo.1' involves an
1888 _execution_ of `foo$(EXEEXT)'.
1890 Another context where such errors are common is when distributed
1891 files are built by tools that are built by the package. The pattern is
1894 distributed-file: built-tools distributed-sources
1897 should be changed to
1899 distributed-file: distributed-sources
1900 $(MAKE) $(AM_MAKEFLAGS) built-tools
1903 or you could choose not to distribute `distributed-file', if
1904 cross-compilation does not matter.
1906 The points made through these examples are worth a summary:
1908 * Distributed files should never depend upon non-distributed built
1911 * Distributed files should be distributed with all their
1914 * If a file is _intended_ to be rebuilt by users, then there is no
1915 point in distributing it.
1917 For desperate cases, it's always possible to disable this check by
1918 setting `distcleancheck_listfiles' as documented in *note Checking the
1919 Distribution::. Make sure you do understand the reason why `make
1920 distcheck' complains before you do this. `distcleancheck_listfiles' is
1921 a way to _hide_ errors, not to fix them. You can always do better.
1924 File: automake.info, Node: Flag Variables Ordering, Next: Renamed Objects, Prev: distcleancheck, Up: FAQ
1926 27.6 Flag Variables Ordering
1927 ============================
1929 What is the difference between `AM_CFLAGS', `CFLAGS', and
1932 Why does `automake' output `CPPFLAGS' after
1933 `AM_CPPFLAGS' on compile lines? Shouldn't it be the converse?
1935 My `configure' adds some warning flags into `CXXFLAGS'. In
1936 one `Makefile.am' I would like to append a new flag, however if I
1937 put the flag into `AM_CXXFLAGS' it is prepended to the other
1938 flags, not appended.
1940 Compile Flag Variables
1941 ----------------------
1943 This section attempts to answer all the above questions. We will
1944 mostly discuss `CPPFLAGS' in our examples, but actually the answer
1945 holds for all the compile flags used in Automake: `CCASFLAGS',
1946 `CFLAGS', `CPPFLAGS', `CXXFLAGS', `FCFLAGS', `FFLAGS', `GCJFLAGS',
1947 `LDFLAGS', `LFLAGS', `LIBTOOLFLAGS', `OBJCFLAGS', `RFLAGS', `UPCFLAGS',
1950 `CPPFLAGS', `AM_CPPFLAGS', and `mumble_CPPFLAGS' are three variables
1951 that can be used to pass flags to the C preprocessor (actually these
1952 variables are also used for other languages like C++ or preprocessed
1953 Fortran). `CPPFLAGS' is the user variable (*note User Variables::),
1954 `AM_CPPFLAGS' is the Automake variable, and `mumble_CPPFLAGS' is the
1955 variable specific to the `mumble' target (we call this a per-target
1956 variable, *note Program and Library Variables::).
1958 Automake always uses two of these variables when compiling C sources
1959 files. When compiling an object file for the `mumble' target, the
1960 first variable will be `mumble_CPPFLAGS' if it is defined, or
1961 `AM_CPPFLAGS' otherwise. The second variable is always `CPPFLAGS'.
1963 In the following example,
1965 bin_PROGRAMS = foo bar
1967 bar_SOURCES = main.c
1968 foo_CPPFLAGS = -DFOO
1971 `xyz.o' will be compiled with `$(foo_CPPFLAGS) $(CPPFLAGS)', (because
1972 `xyz.o' is part of the `foo' target), while `main.o' will be compiled
1973 with `$(AM_CPPFLAGS) $(CPPFLAGS)' (because there is no per-target
1974 variable for target `bar').
1976 The difference between `mumble_CPPFLAGS' and `AM_CPPFLAGS' being
1977 clear enough, let's focus on `CPPFLAGS'. `CPPFLAGS' is a user
1978 variable, i.e., a variable that users are entitled to modify in order
1979 to compile the package. This variable, like many others, is documented
1980 at the end of the output of `configure --help'.
1982 For instance, someone who needs to add `/home/my/usr/include' to the
1983 C compiler's search path would configure a package with
1985 ./configure CPPFLAGS='-I /home/my/usr/include'
1987 and this flag would be propagated to the compile rules of all
1990 It is also not uncommon to override a user variable at `make'-time.
1991 Many installers do this with `prefix', but this can be useful with
1992 compiler flags too. For instance, if, while debugging a C++ project,
1993 you need to disable optimization in one specific object file, you can
1997 make CXXFLAGS=-O0 file.o
2000 The reason `$(CPPFLAGS)' appears after `$(AM_CPPFLAGS)' or
2001 `$(mumble_CPPFLAGS)' in the compile command is that users should always
2002 have the last say. It probably makes more sense if you think about it
2003 while looking at the `CXXFLAGS=-O0' above, which should supersede any
2004 other switch from `AM_CXXFLAGS' or `mumble_CXXFLAGS' (and this of
2005 course replaces the previous value of `CXXFLAGS').
2007 You should never redefine a user variable such as `CPPFLAGS' in
2008 `Makefile.am'. Use `automake -Woverride' to diagnose such mistakes.
2011 CPPFLAGS = -DDATADIR=\"$(datadir)\" @CPPFLAGS@
2013 is erroneous. Although this preserves `configure''s value of
2014 `CPPFLAGS', the definition of `DATADIR' will disappear if a user
2015 attempts to override `CPPFLAGS' from the `make' command line.
2017 AM_CPPFLAGS = -DDATADIR=\"$(datadir)\"
2019 is all that is needed here if no per-target flags are used.
2021 You should not add options to these user variables within
2022 `configure' either, for the same reason. Occasionally you need to
2023 modify these variables to perform a test, but you should reset their
2024 values afterwards. In contrast, it is OK to modify the `AM_' variables
2025 within `configure' if you `AC_SUBST' them, but it is rather rare that
2026 you need to do this, unless you really want to change the default
2027 definitions of the `AM_' variables in all `Makefile's.
2029 What we recommend is that you define extra flags in separate
2030 variables. For instance, you may write an Autoconf macro that computes
2031 a set of warning options for the C compiler, and `AC_SUBST' them in
2032 `WARNINGCFLAGS'; you may also have an Autoconf macro that determines
2033 which compiler and which linker flags should be used to link with
2034 library `libfoo', and `AC_SUBST' these in `LIBFOOCFLAGS' and
2035 `LIBFOOLDFLAGS'. Then, a `Makefile.am' could use these variables as
2038 AM_CFLAGS = $(WARNINGCFLAGS)
2039 bin_PROGRAMS = prog1 prog2
2042 prog2_CFLAGS = $(LIBFOOCFLAGS) $(AM_CFLAGS)
2043 prog2_LDFLAGS = $(LIBFOOLDFLAGS)
2045 In this example both programs will be compiled with the flags
2046 substituted into `$(WARNINGCFLAGS)', and `prog2' will additionally be
2047 compiled with the flags required to link with `libfoo'.
2049 Note that listing `AM_CFLAGS' in a per-target `CFLAGS' variable is a
2050 common idiom to ensure that `AM_CFLAGS' applies to every target in a
2053 Using variables like this gives you full control over the ordering of
2054 the flags. For instance, if there is a flag in $(WARNINGCFLAGS) that
2055 you want to negate for a particular target, you can use something like
2056 `prog1_CFLAGS = $(AM_CFLAGS) -no-flag'. If all these flags had been
2057 forcefully appended to `CFLAGS', there would be no way to disable one
2058 flag. Yet another reason to leave user variables to users.
2060 Finally, we have avoided naming the variable of the example
2061 `LIBFOO_LDFLAGS' (with an underscore) because that would cause Automake
2062 to think that this is actually a per-target variable (like
2063 `mumble_LDFLAGS') for some non-declared `LIBFOO' target.
2068 There are other variables in Automake that follow similar principles to
2069 allow user options. For instance, Texinfo rules (*note Texinfo::) use
2070 `MAKEINFOFLAGS' and `AM_MAKEINFOFLAGS'. Similarly, DejaGnu tests
2071 (*note DejaGnu Tests::) use `RUNTESTDEFAULTFLAGS' and
2072 `AM_RUNTESTDEFAULTFLAGS'. The tags and ctags rules (*note Tags::) use
2073 `ETAGSFLAGS', `AM_ETAGSFLAGS', `CTAGSFLAGS', and `AM_CTAGSFLAGS'. Java
2074 rules (*note Java::) use `JAVACFLAGS' and `AM_JAVACFLAGS'. None of
2075 these rules support per-target flags (yet).
2077 To some extent, even `AM_MAKEFLAGS' (*note Subdirectories::) obeys
2078 this naming scheme. The slight difference is that `MAKEFLAGS' is
2079 passed to sub-`make's implicitly by `make' itself.
2081 However you should not think that all variables ending with `FLAGS'
2082 follow this convention. For instance, `DISTCHECK_CONFIGURE_FLAGS'
2083 (*note Checking the Distribution::) and `ACLOCAL_AMFLAGS' (see *note
2084 Rebuilding:: and *note Local Macros::), are two variables that are only
2085 useful to the maintainer and have no user counterpart.
2087 `ARFLAGS' (*note A Library::) is usually defined by Automake and has
2088 neither `AM_' nor per-target cousin.
2090 Finally you should not think that the existence of a per-target
2091 variable implies the existance of an `AM_' variable or of a user
2092 variable. For instance, the `mumble_LDADD' per-target variable
2093 overrides the makefile-wide `LDADD' variable (which is not a user
2094 variable), and `mumble_LIBADD' exists only as a per-target variable.
2095 *Note Program and Library Variables::.
2098 File: automake.info, Node: Renamed Objects, Next: Per-Object Flags, Prev: Flag Variables Ordering, Up: FAQ
2100 27.7 Why are object files sometimes renamed?
2101 ============================================
2103 This happens when per-target compilation flags are used. Object files
2104 need to be renamed just in case they would clash with object files
2105 compiled from the same sources, but with different flags. Consider the
2108 bin_PROGRAMS = true false
2109 true_SOURCES = generic.c
2110 true_CPPFLAGS = -DEXIT_CODE=0
2111 false_SOURCES = generic.c
2112 false_CPPFLAGS = -DEXIT_CODE=1
2113 Obviously the two programs are built from the same source, but it
2114 would be bad if they shared the same object, because `generic.o' cannot
2115 be built with both `-DEXIT_CODE=0' _and_ `-DEXIT_CODE=1'. Therefore
2116 `automake' outputs rules to build two different objects:
2117 `true-generic.o' and `false-generic.o'.
2119 `automake' doesn't actually look whether source files are shared to
2120 decide if it must rename objects. It will just rename all objects of a
2121 target as soon as it sees per-target compilation flags used.
2123 It's OK to share object files when per-target compilation flags are
2124 not used. For instance, `true' and `false' will both use `version.o'
2125 in the following example.
2127 AM_CPPFLAGS = -DVERSION=1.0
2128 bin_PROGRAMS = true false
2129 true_SOURCES = true.c version.c
2130 false_SOURCES = false.c version.c
2132 Note that the renaming of objects is also affected by the
2133 `_SHORTNAME' variable (*note Program and Library Variables::).
2136 File: automake.info, Node: Per-Object Flags, Next: Multiple Outputs, Prev: Renamed Objects, Up: FAQ
2138 27.8 Per-Object Flags Emulation
2139 ===============================
2141 One of my source files needs to be compiled with different flags. How
2144 Automake supports per-program and per-library compilation flags (see
2145 *note Program and Library Variables:: and *note Flag Variables
2146 Ordering::). With this you can define compilation flags that apply to
2147 all files compiled for a target. For instance, in
2150 foo_SOURCES = foo.c foo.h bar.c bar.h main.c
2151 foo_CFLAGS = -some -flags
2153 `foo-foo.o', `foo-bar.o', and `foo-main.o' will all be compiled with
2154 `-some -flags'. (If you wonder about the names of these object files,
2155 see *note Renamed Objects::.) Note that `foo_CFLAGS' gives the flags
2156 to use when compiling all the C sources of the _program_ `foo', it has
2157 nothing to do with `foo.c' or `foo-foo.o' specifically.
2159 What if `foo.c' needs to be compiled into `foo.o' using some
2160 specific flags, that none of the other files requires? Obviously
2161 per-program flags are not directly applicable here. Something like
2162 per-object flags are expected, i.e., flags that would be used only when
2163 creating `foo-foo.o'. Automake does not support that, however this is
2164 easy to simulate using a library that contains only that object, and
2165 compiling this library with per-library flags.
2168 foo_SOURCES = bar.c bar.h main.c
2169 foo_CFLAGS = -some -flags
2170 foo_LDADD = libfoo.a
2171 noinst_LIBRARIES = libfoo.a
2172 libfoo_a_SOURCES = foo.c foo.h
2173 libfoo_a_CFLAGS = -some -other -flags
2175 Here `foo-bar.o' and `foo-main.o' will all be compiled with `-some
2176 -flags', while `libfoo_a-foo.o' will be compiled using `-some -other
2177 -flags'. Eventually, all three objects will be linked to form `foo'.
2179 This trick can also be achieved using Libtool convenience libraries,
2180 for instance `noinst_LTLIBRARIES = libfoo.la' (*note Libtool
2181 Convenience Libraries::).
2183 Another tempting idea to implement per-object flags is to override
2184 the compile rules `automake' would output for these files. Automake
2185 will not define a rule for a target you have defined, so you could
2186 think about defining the `foo-foo.o: foo.c' rule yourself. We
2187 recommend against this, because this is error prone. For instance, if
2188 you add such a rule to the first example, it will break the day you
2189 decide to remove `foo_CFLAGS' (because `foo.c' will then be compiled as
2190 `foo.o' instead of `foo-foo.o', *note Renamed Objects::). Also in
2191 order to support dependency tracking, the two `.o'/`.obj' extensions,
2192 and all the other flags variables involved in a compilation, you will
2193 end up modifying a copy of the rule previously output by `automake' for
2194 this file. If a new release of Automake generates a different rule,
2195 your copy will need to be updated by hand.
2198 File: automake.info, Node: Multiple Outputs, Next: Hard-Coded Install Paths, Prev: Per-Object Flags, Up: FAQ
2200 27.9 Handling Tools that Produce Many Outputs
2201 =============================================
2203 This section describes a `make' idiom that can be used when a tool
2204 produces multiple output files. It is not specific to Automake and can
2205 be used in ordinary `Makefile's.
2207 Suppose we have a program called `foo' that will read one file
2208 called `data.foo' and produce two files named `data.c' and `data.h'.
2209 We want to write a `Makefile' rule that captures this one-to-two
2212 The naive rule is incorrect:
2214 # This is incorrect.
2215 data.c data.h: data.foo
2218 What the above rule really says is that `data.c' and `data.h' each
2219 depend on `data.foo', and can each be built by running `foo data.foo'.
2220 In other words it is equivalent to:
2222 # We do not want this.
2228 which means that `foo' can be run twice. Usually it will not be run
2229 twice, because `make' implementations are smart enough to check for the
2230 existence of the second file after the first one has been built; they
2231 will therefore detect that it already exists. However there are a few
2232 situations where it can run twice anyway:
2234 * The most worrying case is when running a parallel `make'. If
2235 `data.c' and `data.h' are built in parallel, two `foo data.foo'
2236 commands will run concurrently. This is harmful.
2238 * Another case is when the dependency (here `data.foo') is (or
2239 depends upon) a phony target.
2241 A solution that works with parallel `make' but not with phony
2242 dependencies is the following:
2244 data.c data.h: data.foo
2248 The above rules are equivalent to
2252 data.h: data.foo data.c
2254 therefore a parallel `make' will have to serialize the builds of
2255 `data.c' and `data.h', and will detect that the second is no longer
2256 needed once the first is over.
2258 Using this pattern is probably enough for most cases. However it
2259 does not scale easily to more output files (in this scheme all output
2260 files must be totally ordered by the dependency relation), so we will
2261 explore a more complicated solution.
2263 Another idea is to write the following:
2265 # There is still a problem with this one.
2270 The idea is that `foo data.foo' is run only when `data.c' needs to be
2271 updated, but we further state that `data.h' depends upon `data.c'.
2272 That way, if `data.h' is required and `data.foo' is out of date, the
2273 dependency on `data.c' will trigger the build.
2275 This is almost perfect, but suppose we have built `data.h' and
2276 `data.c', and then we erase `data.h'. Then, running `make data.h' will
2277 not rebuild `data.h'. The above rules just state that `data.c' must be
2278 up-to-date with respect to `data.foo', and this is already the case.
2280 What we need is a rule that forces a rebuild when `data.h' is
2281 missing. Here it is:
2286 ## Recover from the removal of $@
2287 @if test -f $@; then :; else \
2289 $(MAKE) $(AM_MAKEFLAGS) data.c; \
2292 The above scheme can be extended to handle more outputs and more
2293 inputs. One of the outputs is selected to serve as a witness to the
2294 successful completion of the command, it depends upon all inputs, and
2295 all other outputs depend upon it. For instance, if `foo' should
2296 additionally read `data.bar' and also produce `data.w' and `data.x', we
2299 data.c: data.foo data.bar
2300 foo data.foo data.bar
2301 data.h data.w data.x: data.c
2302 ## Recover from the removal of $@
2303 @if test -f $@; then :; else \
2305 $(MAKE) $(AM_MAKEFLAGS) data.c; \
2308 However there are now two minor problems in this setup. One is
2309 related to the timestamp ordering of `data.h', `data.w', `data.x', and
2310 `data.c'. The other one is a race condition if a parallel `make'
2311 attempts to run multiple instances of the recover block at once.
2313 Let us deal with the first problem. `foo' outputs four files, but
2314 we do not know in which order these files are created. Suppose that
2315 `data.h' is created before `data.c'. Then we have a weird situation.
2316 The next time `make' is run, `data.h' will appear older than `data.c',
2317 the second rule will be triggered, a shell will be started to execute
2318 the `if...fi' command, but actually it will just execute the `then'
2319 branch, that is: nothing. In other words, because the witness we
2320 selected is not the first file created by `foo', `make' will start a
2321 shell to do nothing each time it is run.
2323 A simple riposte is to fix the timestamps when this happens.
2325 data.c: data.foo data.bar
2326 foo data.foo data.bar
2327 data.h data.w data.x: data.c
2328 @if test -f $@; then \
2331 ## Recover from the removal of $@
2333 $(MAKE) $(AM_MAKEFLAGS) data.c; \
2336 Another solution is to use a different and dedicated file as witness,
2337 rather than using any of `foo''s outputs.
2339 data.stamp: data.foo data.bar
2342 foo data.foo data.bar
2344 data.c data.h data.w data.x: data.stamp
2345 ## Recover from the removal of $@
2346 @if test -f $@; then :; else \
2348 $(MAKE) $(AM_MAKEFLAGS) data.stamp; \
2351 `data.tmp' is created before `foo' is run, so it has a timestamp
2352 older than output files output by `foo'. It is then renamed to
2353 `data.stamp' after `foo' has run, because we do not want to update
2354 `data.stamp' if `foo' fails.
2356 This solution still suffers from the second problem: the race
2357 condition in the recover rule. If, after a successful build, a user
2358 erases `data.c' and `data.h', and runs `make -j', then `make' may start
2359 both recover rules in parallel. If the two instances of the rule
2360 execute `$(MAKE) $(AM_MAKEFLAGS) data.stamp' concurrently the build is
2361 likely to fail (for instance, the two rules will create `data.tmp', but
2362 only one can rename it).
2364 Admittedly, such a weird situation does not arise during ordinary
2365 builds. It occurs only when the build tree is mutilated. Here
2366 `data.c' and `data.h' have been explicitly removed without also
2367 removing `data.stamp' and the other output files. `make clean; make'
2368 will always recover from these situations even with parallel makes, so
2369 you may decide that the recover rule is solely to help non-parallel
2370 make users and leave things as-is. Fixing this requires some locking
2371 mechanism to ensure only one instance of the recover rule rebuilds
2372 `data.stamp'. One could imagine something along the following lines.
2374 data.c data.h data.w data.x: data.stamp
2375 ## Recover from the removal of $@
2376 @if test -f $@; then :; else \
2377 trap 'rm -rf data.lock data.stamp' 1 2 13 15; \
2378 ## mkdir is a portable test-and-set
2379 if mkdir data.lock 2>/dev/null; then \
2380 ## This code is being executed by the first process.
2382 $(MAKE) $(AM_MAKEFLAGS) data.stamp; \
2383 result=$$?; rm -rf data.lock; exit $$result; \
2385 ## This code is being executed by the follower processes.
2386 ## Wait until the first process is done.
2387 while test -d data.lock; do sleep 1; done; \
2388 ## Succeed if and only if the first process succeeded.
2389 test -f data.stamp; \
2393 Using a dedicated witness, like `data.stamp', is very handy when the
2394 list of output files is not known beforehand. As an illustration,
2395 consider the following rules to compile many `*.el' files into `*.elc'
2396 files in a single command. It does not matter how `ELFILES' is defined
2397 (as long as it is not empty: empty targets are not accepted by POSIX).
2399 ELFILES = one.el two.el three.el ...
2400 ELCFILES = $(ELFILES:=c)
2402 elc-stamp: $(ELFILES)
2405 $(elisp_comp) $(ELFILES)
2408 $(ELCFILES): elc-stamp
2409 ## Recover from the removal of $@
2410 @if test -f $@; then :; else \
2411 trap 'rm -rf elc-lock elc-stamp' 1 2 13 15; \
2412 if mkdir elc-lock 2>/dev/null; then \
2413 ## This code is being executed by the first process.
2415 $(MAKE) $(AM_MAKEFLAGS) elc-stamp; \
2418 ## This code is being executed by the follower processes.
2419 ## Wait until the first process is done.
2420 while test -d elc-lock; do sleep 1; done; \
2421 ## Succeed if and only if the first process succeeded.
2422 test -f elc-stamp; exit $$?; \
2426 For completeness it should be noted that GNU `make' is able to
2427 express rules with multiple output files using pattern rules (*note
2428 Pattern Rule Examples: (make)Pattern Examples.). We do not discuss
2429 pattern rules here because they are not portable, but they can be
2430 convenient in packages that assume GNU `make'.
2433 File: automake.info, Node: Hard-Coded Install Paths, Next: Debugging Make Rules, Prev: Multiple Outputs, Up: FAQ
2435 27.10 Installing to Hard-Coded Locations
2436 ========================================
2438 My package needs to install some configuration file. I tried to use
2439 the following rule, but `make distcheck' fails. Why?
2442 $(INSTALL_DATA) $(srcdir)/afile $(DESTDIR)/etc/afile
2444 My package needs to populate the installation directory of another
2445 package at install-time. I can easily compute that installation
2446 directory in `configure', but if I install files therein,
2447 `make distcheck' fails. How else should I do?
2449 These two setups share their symptoms: `make distcheck' fails
2450 because they are installing files to hard-coded paths. In the later
2451 case the path is not really hard-coded in the package, but we can
2452 consider it to be hard-coded in the system (or in whichever tool that
2453 supplies the path). As long as the path does not use any of the
2454 standard directory variables (`$(prefix)', `$(bindir)', `$(datadir)',
2455 etc.), the effect will be the same: user-installations are impossible.
2457 When a (non-root) user wants to install a package, he usually has no
2458 right to install anything in `/usr' or `/usr/local'. So he does
2459 something like `./configure --prefix ~/usr' to install package in his
2462 If a package attempts to install something to some hard-coded path
2463 (e.g., `/etc/afile'), regardless of this `--prefix' setting, then the
2464 installation will fail. `make distcheck' performs such a `--prefix'
2465 installation, hence it will fail too.
2467 Now, there are some easy solutions.
2469 The above `install-data-local' example for installing `/etc/afile'
2470 would be better replaced by
2472 sysconf_DATA = afile
2474 by default `sysconfdir' will be `$(prefix)/etc', because this is what
2475 the GNU Standards require. When such a package is installed on an FHS
2476 compliant system, the installer will have to set `--sysconfdir=/etc'.
2477 As the maintainer of the package you should not be concerned by such
2478 site policies: use the appropriate standard directory variable to
2479 install your files so that the installer can easily redefine these
2480 variables to match their site conventions.
2482 Installing files that should be used by another package is slightly
2483 more involved. Let's take an example and assume you want to install a
2484 shared library that is a Python extension module. If you ask Python
2485 where to install the library, it will answer something like this:
2487 % python -c 'from distutils import sysconfig;
2488 print sysconfig.get_python_lib(1,0)'
2489 /usr/lib/python2.5/site-packages
2491 If you indeed use this absolute path to install your shared library,
2492 non-root users will not be able to install the package, hence distcheck
2495 Let's do better. The `sysconfig.get_python_lib()' function actually
2496 accepts a third argument that will replace Python's installation prefix.
2498 % python -c 'from distutils import sysconfig;
2499 print sysconfig.get_python_lib(1,0,"${exec_prefix}")'
2500 ${exec_prefix}/lib/python2.5/site-packages
2502 You can also use this new path. If you do
2503 * root users can install your package with the same `--prefix' as
2504 Python (you get the behavior of the previous attempt)
2506 * non-root users can install your package too, they will have the
2507 extension module in a place that is not searched by Python but they
2508 can work around this using environment variables (and if you
2509 installed scripts that use this shared library, it's easy to tell
2510 Python were to look in the beginning of your script, so the script
2511 works in both cases).
2513 The `AM_PATH_PYTHON' macro uses similar commands to define
2514 `$(pythondir)' and `$(pyexecdir)' (*note Python::).
2516 Of course not all tools are as advanced as Python regarding that
2517 substitution of PREFIX. So another strategy is to figure the part of
2518 the installation directory that must be preserved. For instance, here
2519 is how `AM_PATH_LISPDIR' (*note Emacs Lisp::) computes `$(lispdir)':
2521 $EMACS -batch -q -eval '(while load-path
2522 (princ (concat (car load-path) "\n"))
2523 (setq load-path (cdr load-path)))' >conftest.out
2526 -e '/.*\/lib\/x*emacs\/site-lisp$/{
2527 s,.*/lib/\(x*emacs/site-lisp\)$,${libdir}/\1,;p;q;
2529 -e '/.*\/share\/x*emacs\/site-lisp$/{
2530 s,.*/share/\(x*emacs/site-lisp\),${datarootdir}/\1,;p;q;
2534 I.e., it just picks the first directory that looks like
2535 `*/lib/*emacs/site-lisp' or `*/share/*emacs/site-lisp' in the search
2536 path of emacs, and then substitutes `${libdir}' or `${datadir}'
2539 The emacs case looks complicated because it processes a list and
2540 expects two possible layouts, otherwise it's easy, and the benefits for
2541 non-root users are really worth the extra `sed' invocation.
2544 File: automake.info, Node: Debugging Make Rules, Prev: Hard-Coded Install Paths, Up: FAQ
2546 27.11 Debugging Make Rules
2547 ==========================
2549 The rules and dependency trees generated by `automake' can get rather
2550 complex, and leave the developer head-scratching when things don't work
2551 as expected. Besides the debug options provided by the `make' command
2552 (*note Options Summary: (make)Options Summary.), here's a couple of
2553 further hints for debugging makefiles generated by `automake'
2556 * If less verbose output has been enabled in the package with the
2557 `silent-rules' option (*note Options::), you can use `make V=1' to
2558 see the commands being executed.
2560 * `make -n' can help show what would be done without actually doing
2561 it. Note however, that this will _still execute_ commands prefixed
2562 with `+', and, when using GNU `make', commands that contain the
2563 strings `$(MAKE)' or `${MAKE}' (*note Instead of Execution:
2564 (make)Instead of Execution.). Typically, this is helpful to show
2565 what recursive rules would do, but it means that, in your own
2566 rules, you should not mix such recursion with actions that change
2567 any files.(1) Furthermore, note that GNU `make' will update
2568 prerequisites for the `Makefile' file itself even with `-n' (*note
2569 Remaking Makefiles: (make)Remaking Makefiles.).
2571 * `make SHELL="/bin/bash -vx"' can help debug complex rules. *Note
2572 The Make Macro SHELL: (autoconf)The Make Macro SHELL, for some
2573 portability quirks associated with this construct.
2575 ---------- Footnotes ----------
2577 (1) Automake's `dist' and `distcheck' rules had a bug in this regard
2578 in that they created directories even with `-n', but this has been
2579 fixed in Automake 1.11.
2582 File: automake.info, Node: History, Next: Copying This Manual, Prev: FAQ, Up: Top
2584 28 History of Automake
2585 **********************
2587 This chapter presents various aspects of the history of Automake. The
2588 exhausted reader can safely skip it; this will be more of interest to
2589 nostalgic people, or to those curious to learn about the evolution of
2594 * Timeline:: The Automake story.
2595 * Dependency Tracking Evolution:: Evolution of Automatic Dependency Tracking
2596 * Releases:: Statistics about Automake Releases
2599 File: automake.info, Node: Timeline, Next: Dependency Tracking Evolution, Up: History
2604 1994-09-19 First CVS commit.
2605 If we can trust the CVS repository, David J. MacKenzie (djm)
2606 started working on Automake (or AutoMake, as it was spelt then)
2609 The first version of the `automake' script looks as follows.
2617 if test ! -f ${makefile}.am; then
2618 echo "automake: ${makefile}.am: No such honkin' file"
2623 exec 4> ${makefile}.in
2627 From this you can already see that Automake will be about reading
2628 `*.am' file and producing `*.in' files. You cannot see anything
2629 else, but if you also know that David is the one who created
2630 Autoconf two years before you can guess the rest.
2632 Several commits follow, and by the end of the day Automake is
2633 reported to work for GNU fileutils and GNU m4.
2635 The modus operandi is the one that is still used today: variable
2636 assignments in `Makefile.am' files trigger injections of precanned
2637 `Makefile' fragments into the generated `Makefile.in'. The use of
2638 `Makefile' fragments was inspired by the 4.4BSD `make' and include
2639 files, however Automake aims to be portable and to conform to the
2640 GNU standards for `Makefile' variables and targets.
2642 At this point, the most recent release of Autoconf is version 1.11,
2643 and David is preparing to release Autoconf 2.0 in late October.
2644 As a matter of fact, he will barely touch Automake after September.
2646 1994-11-05 David MacKenzie's last commit.
2647 At this point Automake is a 200 line portable shell script, plus
2648 332 lines of `Makefile' fragments. In the `README', David states
2649 his ambivalence between "portable shell" and "more appropriate
2652 I wrote it keeping in mind the possibility of it becoming an
2653 Autoconf macro, so it would run at configure-time. That
2654 would slow configuration down a bit, but allow users to
2655 modify the Makefile.am without needing to fetch the AutoMake
2656 package. And, the Makefile.in files wouldn't need to be
2657 distributed. But all of AutoMake would. So I might
2658 reimplement AutoMake in Perl, m4, or some other more
2659 appropriate language.
2661 Automake is described as "an experimental Makefile generator".
2662 There is no documentation. Adventurous users are referred to the
2663 examples and patches needed to use Automake with GNU m4 1.3,
2664 fileutils 3.9, time 1.6, and development versions of find and
2667 These examples seem to have been lost. However at the time of
2668 writing (10 years later in September, 2004) the FSF still
2669 distributes a package that uses this version of Automake: check
2670 out GNU termutils 2.0.
2672 1995-11-12 Tom Tromey's first commit.
2673 After one year of inactivity, Tom Tromey takes over the package.
2674 Tom was working on GNU cpio back then, and doing this just for fun,
2675 having trouble finding a project to contribute to. So while
2676 hacking he wanted to bring the `Makefile.in' up to GNU standards.
2677 This was hard, and one day he saw Automake on
2678 `ftp://alpha.gnu.org/', grabbed it and tried it out.
2680 Tom didn't talk to djm about it until later, just to make sure he
2681 didn't mind if he made a release. He did a bunch of early
2682 releases to the Gnits folks.
2684 Gnits was (and still is) totally informal, just a few GNU friends
2685 who Franc,ois Pinard knew, who were all interested in making a
2686 common infrastructure for GNU projects, and shared a similar
2687 outlook on how to do it. So they were able to make some progress.
2688 It came along with Autoconf and extensions thereof, and then
2689 Automake from David and Tom (who were both gnitsians). One of
2690 their ideas was to write a document paralleling the GNU standards,
2691 that was more strict in some ways and more detailed. They never
2692 finished the GNITS standards, but the ideas mostly made their way
2695 1995-11-23 Automake 0.20
2696 Besides introducing automatic dependency tracking (*note
2697 Dependency Tracking Evolution::), this version also supplies a
2700 At this time `aclocal' and `AM_INIT_AUTOMAKE' did not exist, so
2701 many things had to be done by hand. For instance, here is what a
2702 configure.in (this is the former name of the `configure.ac' we use
2703 today) must contain in order to use Automake 0.20:
2707 AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE")
2708 AC_DEFINE_UNQUOTED(VERSION, "$VERSION")
2714 (Today all of the above is achieved by `AC_INIT' and
2715 `AM_INIT_AUTOMAKE'.)
2717 Here is how programs are specified in `Makefile.am':
2720 hello_SOURCES = hello.c
2722 This looks pretty much like what we do today, except the
2723 `PROGRAMS' variable has no directory prefix specifying where
2724 `hello' should be installed: all programs are installed in
2725 `$(bindir)'. `LIBPROGRAMS' can be used to specify programs that
2726 must be built but not installed (it is called `noinst_PROGRAMS'
2729 Programs can be built conditionally using `AC_SUBST'itutions:
2732 AM_PROGRAMS = foo bar baz
2734 (`AM_PROGRAMS' has since then been renamed to `EXTRA_PROGRAMS'.)
2736 Similarly scripts, static libraries, and data can be built and
2737 installed using the `LIBRARIES', `SCRIPTS', and `DATA' variables.
2738 However `LIBRARIES' were treated a bit specially in that Automake
2739 did automatically supply the `lib' and `.a' prefixes. Therefore
2740 to build `libcpio.a', one had to write
2745 Extra files to distribute must be listed in `DIST_OTHER' (the
2746 ancestor of `EXTRA_DIST'). Also extra directories that are to be
2747 distributed should appear in `DIST_SUBDIRS', but the manual
2748 describes this as a temporary ugly hack (today extra directories
2749 should also be listed in `EXTRA_DIST', and `DIST_SUBDIRS' is used
2750 for another purpose, *note Conditional Subdirectories::).
2752 1995-11-26 Automake 0.21
2753 In less time than it takes to cook a frozen pizza, Tom rewrites
2754 Automake using Perl. At this time Perl 5 is only one year old, and
2755 Perl 4.036 is in use at many sites. Supporting several Perl
2756 versions has been a source of problems through the whole history
2759 If you never used Perl 4, imagine Perl 5 without objects, without
2760 `my' variables (only dynamically scoped `local' variables),
2761 without function prototypes, with function calls that needs to be
2762 prefixed with `&', etc. Traces of this old style can still be
2763 found in today's `automake'.
2765 1995-11-28 Automake 0.22
2766 1995-11-29 Automake 0.23
2769 1995-12-08 Automake 0.24
2770 1995-12-10 Automake 0.25
2771 Releases are raining. 0.24 introduces the uniform naming scheme we
2772 use today, i.e., `bin_PROGRAMS' instead of `PROGRAMS',
2773 `noinst_LIBRARIES' instead of `LIBLIBRARIES', etc. (However
2774 `EXTRA_PROGRAMS' does not exist yet, `AM_PROGRAMS' is still in
2775 use; and `TEXINFOS' and `MANS' still have no directory prefixes.)
2776 Adding support for prefixes like that was one of the major ideas
2777 in `automake'; it has lasted pretty well.
2779 AutoMake is renamed to Automake (Tom seems to recall it was
2780 Franc,ois Pinard's doing).
2782 0.25 fixes a Perl 4 portability bug.
2784 1995-12-18 Jim Meyering starts using Automake in GNU Textutils.
2786 1995-12-31 Franc,ois Pinard starts using Automake in GNU tar.
2788 1996-01-03 Automake 0.26
2789 1996-01-03 Automake 0.27
2790 Of the many changes and suggestions sent by Franc,ois Pinard and
2791 included in 0.26, perhaps the most important is the advice that to
2792 ease customization a user rule or variable definition should always
2793 override an Automake rule or definition.
2795 Gordon Matzigkeit and Jim Meyering are two other early contributors
2796 that have been sending fixes.
2798 0.27 fixes yet another Perl 4 portability bug.
2800 1996-01-13 Automake 0.28
2801 Automake starts scanning `configure.in' for `LIBOBJS' support.
2802 This is an important step because until this version Automake only
2803 knew about the `Makefile.am's it processed. `configure.in' was
2804 Autoconf's world and the link between Autoconf and Automake had to
2805 be done by the `Makefile.am' author. For instance, if `config.h'
2806 was generated by `configure', it was the package maintainer's
2807 responsibility to define the `CONFIG_HEADER' variable in each
2810 Succeeding releases will rely more and more on scanning
2811 `configure.in' to better automate the Autoconf integration.
2813 0.28 also introduces the `AUTOMAKE_OPTIONS' variable and the
2814 `--gnu' and `--gnits' options, the latter being stricter.
2816 1996-02-07 Automake 0.29
2817 Thanks to `configure.in' scanning, `CONFIG_HEADER' is gone, and
2818 rebuild rules for `configure'-generated file are automatically
2821 `TEXINFOS' and `MANS' converted to the uniform naming scheme.
2823 1996-02-24 Automake 0.30
2824 The test suite is born. It contains 9 tests. From now on test
2825 cases will be added pretty regularly (*note Releases::), and this
2826 proved to be really helpful later on.
2828 `EXTRA_PROGRAMS' finally replaces `AM_PROGRAMS'.
2830 All the third-party Autoconf macros, written mostly by Franc,ois
2831 Pinard (and later Jim Meyering), are distributed in Automake's
2832 hand-written `aclocal.m4' file. Package maintainers are expected
2833 to extract the necessary macros from this file. (In previous
2834 versions you had to copy and paste them from the manual...)
2836 1996-03-11 Automake 0.31
2837 The test suite in 0.30 was run via a long `check-local' rule. Upon
2838 Ulrich Drepper's suggestion, 0.31 makes it an Automake rule output
2839 whenever the `TESTS' variable is defined.
2841 `DIST_OTHER' is renamed to `EXTRA_DIST', and the `check_' prefix
2842 is introduced. The syntax is now the same as today.
2844 1996-03-15 Gordon Matzigkeit starts writing libtool.
2846 1996-04-27 Automake 0.32
2847 `-hook' targets are introduced; an idea from Dieter Baron.
2849 `*.info' files, which were output in the build directory are now
2850 built in the source directory, because they are distributed. It
2851 seems these files like to move back and forth as that will happen
2852 again in future versions.
2854 1996-05-18 Automake 0.33
2855 Gord Matzigkeit's main two contributions:
2857 * very preliminary libtool support
2859 * the distcheck rule
2861 Although they were very basic at this point, these are probably
2862 among the top features for Automake today.
2864 Jim Meyering also provides the infamous `jm_MAINTAINER_MODE',
2865 since then renamed to `AM_MAINTAINER_MODE' and abandoned by its
2866 author (*note maintainer-mode::).
2868 1996-05-28 Automake 1.0
2869 After only six months of heavy development, the `automake' script
2870 is 3134 lines long, plus 973 lines of `Makefile' fragments. The
2871 package has 30 pages of documentation, and 38 test cases.
2872 `aclocal.m4' contains 4 macros.
2874 From now on and until version 1.4, new releases will occur at a
2875 rate of about one a year. 1.1 did not exist, actually 1.1b to
2876 1.1p have been the name of beta releases for 1.2. This is the
2877 first time Automake uses suffix letters to designate beta
2878 releases, a habit that lasts.
2880 1996-10-10 Kevin Dalley packages Automake 1.0 for Debian GNU/Linux.
2882 1996-11-26 David J. MacKenzie releases Autoconf 2.12.
2883 Between June and October, the Autoconf development is almost
2884 stalled. Roland McGrath has been working at the beginning of the
2885 year. David comes back in November to release 2.12, but he won't
2886 touch Autoconf anymore after this year, and Autoconf then really
2887 stagnates. The desolate Autoconf `ChangeLog' for 1997 lists only
2890 1997-02-28 <automake@gnu.ai.mit.edu> list alive
2891 The mailing list is announced as follows:
2892 I've created the "automake" mailing list. It is
2893 "automake@gnu.ai.mit.edu". Administrivia, as always, to
2894 automake-request@gnu.ai.mit.edu.
2896 The charter of this list is discussion of automake, autoconf, and
2897 other configuration/portability tools (e.g., libtool). It is expected
2898 that discussion will range from pleas for help all the way up to
2901 This list is archived on the FSF machines. Offhand I don't know if
2902 you can get the archive without an account there.
2904 This list is open to anybody who wants to join. Tell all your
2908 Before that people were discussing Automake privately, on the Gnits
2909 mailing list (which is not public either), and less frequently on
2912 `gnu.ai.mit.edu' is now `gnu.org', in case you never noticed. The
2913 archives of the early years of the `automake@gnu.org' list have
2914 been lost, so today it is almost impossible to find traces of
2915 discussions that occurred before 1999. This has been annoying
2916 more than once, as such discussions can be useful to understand
2917 the rationale behind a piece of uncommented code that was
2918 introduced back then.
2920 1997-06-22 Automake 1.2
2921 Automake developments continues, and more and more new Autoconf
2922 macros are required. Distributing them in `aclocal.m4' and
2923 requiring people to browse this file to extract the relevant
2924 macros becomes uncomfortable. Ideally, some of them should be
2925 contributed to Autoconf so that they can be used directly, however
2926 Autoconf is currently inactive. Automake 1.2 consequently
2927 introduces `aclocal' (`aclocal' was actually started on
2928 1996-07-28), a tool that automatically constructs an `aclocal.m4'
2929 file from a repository of third-party macros. Because Autoconf has
2930 stalled, Automake also becomes a kind of repository for such
2931 third-party macros, even macros completely unrelated to Automake
2932 (for instance macros that fix broken Autoconf macros).
2934 The 1.2 release contains 20 macros, including the
2935 `AM_INIT_AUTOMAKE' macro that simplifies the creation of
2938 Libtool is fully supported using `*_LTLIBRARIES'.
2940 The missing script is introduced by Franc,ois Pinard; it is meant
2941 to be a better solution than `AM_MAINTAINER_MODE' (*note
2944 Conditionals support was implemented by Ian Lance Taylor. At the
2945 time, Tom and Ian were working on an internal project at Cygnus.
2946 They were using ILU, which is pretty similar to CORBA. They
2947 wanted to integrate ILU into their build, which was all
2948 `configure'-based, and Ian thought that adding conditionals to
2949 `automake' was simpler than doing all the work in `configure'
2950 (which was the standard at the time). So this was actually funded
2953 This very useful but tricky feature will take a lot of time to
2954 stabilize. (At the time this text is written, there are still
2955 primaries that have not been updated to support conditional
2956 definitions in Automake 1.9.)
2958 The `automake' script has almost doubled: 6089 lines of Perl, plus
2959 1294 lines of `Makefile' fragments.
2961 1997-07-08 Gordon Matzigkeit releases Libtool 1.0.
2963 1998-04-05 Automake 1.3
2964 This is a small advance compared to 1.2. It adds support for
2965 assembly, and preliminary support for Java.
2967 Perl 5.004_04 is out, but fixes to support Perl 4 are still
2968 regularly submitted whenever Automake breaks it.
2970 1998-09-06 `sourceware.cygnus.com' is on-line.
2971 Sourceware was setup by Jason Molenda to host open source projects.
2973 1998-09-19 Automake CVS repository moved to `sourceware.cygnus.com'
2974 1998-10-26 `sourceware.cygnus.com' announces it hosts Automake:
2975 Automake is now hosted on `sourceware.cygnus.com'. It has a
2976 publicly accessible CVS repository. This CVS repository is a copy
2977 of the one Tom was using on his machine, which in turn is based on
2978 a copy of the CVS repository of David MacKenzie. This is why we
2979 still have to full source history. (Automake was on Sourceware
2980 until 2007-10-29, when it moved to a git repository on
2981 `savannah.gnu.org', but the Sourceware host had been renamed to
2982 `sources.redhat.com'.)
2984 The oldest file in the administrative directory of the CVS
2985 repository that was created on Sourceware is dated 1998-09-19,
2986 while the announcement that `automake' and `autoconf' had joined
2987 `sourceware' was made on 1998-10-26. They were among the first
2988 projects to be hosted there.
2990 The heedful reader will have noticed Automake was exactly 4 years
2993 1999-01-05 Ben Elliston releases Autoconf 2.13.
2995 1999-01-14 Automake 1.4
2996 This release adds support for Fortran 77 and for the `include'
2997 statement. Also, `+=' assignments are introduced, but it is still
2998 quite easy to fool Automake when mixing this with conditionals.
3000 These two releases, Automake 1.4 and Autoconf 2.13 make a duo that
3001 will be used together for years.
3003 `automake' is 7228 lines, plus 1591 lines of Makefile fragment, 20
3004 macros (some 1.3 macros were finally contributed back to
3005 Autoconf), 197 test cases, and 51 pages of documentation.
3007 1999-03-27 The `user-dep-branch' is created on the CVS repository.
3008 This implements a new dependency tracking schemed that should be
3009 able to handle automatic dependency tracking using any compiler
3010 (not just gcc) and any make (not just GNU `make'). In addition,
3011 the new scheme should be more reliable than the old one, as
3012 dependencies are generated on the end user's machine. Alexandre
3013 Oliva creates depcomp for this purpose.
3015 *Note Dependency Tracking Evolution::, for more details about the
3016 evolution of automatic dependency tracking in Automake.
3018 1999-11-21 The `user-dep-branch' is merged into the main trunk.
3019 This was a huge problem since we also had patches going in on the
3020 trunk. The merge took a long time and was very painful.
3023 Since September 1999 and until 2003, Akim Demaille will be
3024 zealously revamping Autoconf.
3026 I think the next release should be called "3.0".
3027 Let's face it: you've basically rewritten autoconf.
3028 Every weekend there are 30 new patches.
3029 I don't see how we could call this "2.15" with a straight
3031 - Tom Tromey on <autoconf@gnu.org>
3033 Actually Akim works like a submarine: he will pile up patches
3034 while he works off-line during the weekend, and flush them in
3035 batch when he resurfaces on Monday.
3038 On this Wednesday, Autoconf 2.49c, the last beta before Autoconf
3039 2.50 is out, and Akim has to find something to do during his
3043 Akim sends a batch of 14 patches to <automake@gnu.org>.
3045 Aiieeee! I was dreading the day that the Demaillator turned
3046 his sights on automake... and now it has arrived! - Tom Tromey
3048 It's only the beginning: in two months he will send 192 patches.
3049 Then he would slow down so Tom can catch up and review all this.
3050 Initially Tom actually read all these patches, then he probably
3051 trustingly answered OK to most of them, and finally gave up and
3052 let Akim apply whatever he wanted. There was no way to keep up
3053 with that patch rate.
3055 Anyway the patch below won't apply since it predates Akim's
3056 sourcequake; I have yet to figure where the relevant passage
3057 has been moved :) - Alexandre Duret-Lutz
3059 All these patches were sent to and discussed on
3060 <automake@gnu.org>, so subscribed users were literally drowning in
3061 technical mails. Eventually, the <automake-patches@gnu.org>
3062 mailing list was created in May.
3064 Year after year, Automake had drifted away from its initial design:
3065 construct `Makefile.in' by assembling various `Makefile'
3066 fragments. In 1.4, lots of `Makefile' rules are being emitted at
3067 various places in the `automake' script itself; this does not help
3068 ensuring a consistent treatment of these rules (for instance
3069 making sure that user-defined rules override Automake's own rules).
3070 One of Akim's goal was moving all these hard-coded rules to
3071 separate `Makefile' fragments, so the logic could be centralized
3072 in a `Makefile' fragment processor.
3074 Another significant contribution of Akim is the interface with the
3075 "trace" feature of Autoconf. The way to scan `configure.in' at
3076 this time was to read the file and grep the various macro of
3077 interest to Automake. Doing so could break in many unexpected
3078 ways; `automake' could miss some definition (for instance
3079 `AC_SUBST([$1], [$2])' where the arguments are known only when M4
3080 is run), or conversely it could detect some macro that was not
3081 expanded (because it is called conditionally). In the CVS version
3082 of Autoconf, Akim had implemented the `--trace' option, which
3083 provides accurate information about where macros are actually
3084 called and with what arguments. Akim will equip Automake with a
3085 second `configure.in' scanner that uses this `--trace' interface.
3086 Since it was not sensible to drop the Autoconf 2.13 compatibility
3087 yet, this experimental scanner was only used when an environment
3088 variable was set, the traditional grep-scanner being still the
3091 2001-04-25 Gary V. Vaughan releases Libtool 1.4
3092 It has been more than two years since Automake 1.4, CVS Automake
3093 has suffered lot's of heavy changes and still is not ready for
3094 release. Libtool 1.4 had to be distributed with a patch against
3097 2001-05-08 Automake 1.4-p1
3098 2001-05-24 Automake 1.4-p2
3099 Gary V. Vaughan, the principal Libtool maintainer, makes a "patch
3100 release" of Automake:
3102 The main purpose of this release is to have a stable automake
3103 which is compatible with the latest stable libtool.
3105 The release also contains obvious fixes for bugs in Automake 1.4,
3106 some of which were reported almost monthly.
3108 2001-05-21 Akim Demaille releases Autoconf 2.50
3110 2001-06-07 Automake 1.4-p3
3111 2001-06-10 Automake 1.4-p4
3112 2001-07-15 Automake 1.4-p5
3113 Gary continues his patch-release series. These also add support
3114 for some new Autoconf 2.50 idioms. Essentially, Autoconf now
3115 advocates `configure.ac' over `configure.in', and it introduces a
3116 new syntax for `AC_OUTPUT'ing files.
3118 2001-08-23 Automake 1.5
3119 A major and long-awaited release, that comes more than two years
3120 after 1.4. It brings many changes, among which:
3121 * The new dependency tracking scheme that uses `depcomp'.
3122 Aside from the improvement on the dependency tracking itself
3123 (*note Dependency Tracking Evolution::), this also
3124 streamlines the use of `automake'-generated `Makefile.in's as
3125 the `Makefile.in's used during development are now the same
3126 as those used in distributions. Before that the
3127 `Makefile.in's generated for maintainers required GNU `make'
3128 and GCC, they were different from the portable `Makefile'
3129 generated for distribution; this was causing some confusion.
3131 * Support for per-target compilation flags.
3133 * Support for reference to files in subdirectories in most
3134 `Makefile.am' variables.
3136 * Introduction of the `dist_', `nodist_', and `nobase_'
3139 * Perl 4 support is finally dropped.
3141 1.5 did break several packages that worked with 1.4. Enough so
3142 that Linux distributions could not easily install the new Automake
3143 version without breaking many of the packages for which they had
3146 Some of these breakages were effectively bugs that would
3147 eventually be fixed in the next release. However, a lot of damage
3148 was caused by some changes made deliberately to render Automake
3149 stricter on some setup we did consider bogus. For instance, `make
3150 distcheck' was improved to check that `make uninstall' did remove
3151 all the files `make install' installed, that `make distclean' did
3152 not omit some file, and that a VPATH build would work even if the
3153 source directory was read-only. Similarly, Automake now rejects
3154 multiple definitions of the same variable (because that would mix
3155 very badly with conditionals), and `+=' assignments with no
3156 previous definition. Because these changes all occurred suddenly
3157 after 1.4 had been established for more than two years, it hurt
3160 To make matter worse, meanwhile Autoconf (now at version 2.52) was
3161 facing similar troubles, for similar reasons.
3163 2002-03-05 Automake 1.6
3164 This release introduced versioned installation (*note API
3165 Versioning::). This was mainly pushed by Havoc Pennington, taking
3166 the GNOME source tree as motive: due to incompatibilities between
3167 the autotools it's impossible for the GNOME packages to switch to
3168 Autoconf 2.53 and Automake 1.5 all at once, so they are currently
3169 stuck with Autoconf 2.13 and Automake 1.4.
3171 The idea was to call this version `automake-1.6', call all its
3172 bug-fix versions identically, and switch to `automake-1.7' for the
3173 next release that adds new features or changes some rules. This
3174 scheme implies maintaining a bug-fix branch in addition to the
3175 development trunk, which means more work from the maintainer, but
3176 providing regular bug-fix releases proved to be really worthwhile.
3178 Like 1.5, 1.6 also introduced a bunch of incompatibilities,
3179 intentional or not. Perhaps the more annoying was the dependence
3180 on the newly released Autoconf 2.53. Autoconf seemed to have
3181 stabilized enough since its explosive 2.50 release and included
3182 changes required to fix some bugs in Automake. In order to
3183 upgrade to Automake 1.6, people now had to upgrade Autoconf too;
3184 for some packages it was no picnic.
3186 While versioned installation helped people to upgrade, it also
3187 unfortunately allowed people not to upgrade. At the time of
3188 writing, some Linux distributions are shipping packages for
3189 Automake 1.4, 1.5, 1.6, 1.7, 1.8, and 1.9. Most of these still
3190 install 1.4 by default. Some distribution also call 1.4 the
3191 "stable" version, and present "1.9" as the development version;
3192 this does not really makes sense since 1.9 is way more solid than
3193 1.4. All this does not help the newcomer.
3195 2002-04-11 Automake 1.6.1
3196 1.6, and the upcoming 1.4-p6 release were the last release by Tom.
3197 This one and those following will be handled by Alexandre
3198 Duret-Lutz. Tom is still around, and will be there until about
3199 1.7, but his interest into Automake is drifting away towards
3200 projects like `gcj'.
3202 Alexandre has been using Automake since 2000, and started to
3203 contribute mostly on Akim's incitement (Akim and Alexandre have
3204 been working in the same room from 1999 to 2002). In 2001 and
3205 2002 he had a lot of free time to enjoy hacking Automake.
3207 2002-06-14 Automake 1.6.2
3209 2002-07-28 Automake 1.6.3
3210 2002-07-28 Automake 1.4-p6
3211 Two releases on the same day. 1.6.3 is a bug-fix release.
3213 Tom Tromey backported the versioned installation mechanism on the
3214 1.4 branch, so that Automake 1.6.x and Automake 1.4-p6 could be
3215 installed side by side. Another request from the GNOME folks.
3217 2002-09-25 Automake 1.7
3218 This release switches to the new `configure.ac' scanner Akim was
3219 experimenting in 1.5.
3221 2002-10-16 Automake 1.7.1
3222 2002-12-06 Automake 1.7.2
3223 2003-02-20 Automake 1.7.3
3224 2003-04-23 Automake 1.7.4
3225 2003-05-18 Automake 1.7.5
3226 2003-07-10 Automake 1.7.6
3227 2003-09-07 Automake 1.7.7
3228 2003-10-07 Automake 1.7.8
3229 Many bug-fix releases. 1.7 lasted because the development version
3230 (upcoming 1.8) was suffering some major internal revamping.
3232 2003-10-26 Automake on screen
3233 Episode 49, `Repercussions', in the third season of the `Alias' TV
3234 show is first aired.
3236 Marshall, one of the characters, is working on a computer virus
3237 that he has to modify before it gets into the wrong hands or
3238 something like that. The screenshots you see do not show any
3239 program code, they show a `Makefile.in' `generated by automake'...
3241 2003-11-09 Automake 1.7.9
3243 2003-12-10 Automake 1.8
3244 The most striking update is probably that of `aclocal'.
3246 `aclocal' now uses `m4_include' in the produced `aclocal.m4' when
3247 the included macros are already distributed with the package (an
3248 idiom used in many packages), which reduces code duplication.
3249 Many people liked that, but in fact this change was really
3250 introduced to fix a bug in rebuild rules: `Makefile.in' must be
3251 rebuilt whenever a dependency of `configure' changes, but all the
3252 `m4' files included in `aclocal.m4' where unknown from `automake'.
3253 Now `automake' can just trace the `m4_include's to discover the
3256 `aclocal' also starts using the `--trace' Autoconf option in order
3257 to discover used macros more accurately. This will turn out to be
3258 very tricky (later releases will improve this) as people had
3259 devised many ways to cope with the limitation of previous
3260 `aclocal' versions, notably using handwritten `m4_include's:
3261 `aclocal' must make sure not to redefine a rule that is already
3262 included by such statement.
3264 Automake also has seen its guts rewritten. Although this rewriting
3265 took a lot of efforts, it is only apparent to the users in that
3266 some constructions previously disallowed by the implementation now
3267 work nicely. Conditionals, Locations, Variable and Rule
3268 definitions, Options: these items on which Automake works have
3269 been rewritten as separate Perl modules, and documented.
3271 2004-01-11 Automake 1.8.1
3272 2004-01-12 Automake 1.8.2
3273 2004-03-07 Automake 1.8.3
3274 2004-04-25 Automake 1.8.4
3275 2004-05-16 Automake 1.8.5
3277 2004-07-28 Automake 1.9
3278 This release tries to simplify the compilation rules it outputs to
3279 reduce the size of the Makefile. The complaint initially come from
3280 the libgcj developers. Their `Makefile.in' generated with
3281 Automake 1.4 and custom build rules (1.4 did not support compiled
3282 Java) is 250KB. The one generated by 1.8 was over 9MB! 1.9 gets
3285 Aside from this it contains mainly minor changes and bug-fixes.
3287 2004-08-11 Automake 1.9.1
3288 2004-09-19 Automake 1.9.2
3289 Automake has ten years. This chapter of the manual was initially
3290 written for this occasion.
3292 2007-10-29 Automake repository moves to `savannah.gnu.org' and uses
3293 git as primary repository.
3297 File: automake.info, Node: Dependency Tracking Evolution, Next: Releases, Prev: Timeline, Up: History
3299 28.2 Dependency Tracking in Automake
3300 ====================================
3302 Over the years Automake has deployed three different dependency
3303 tracking methods. Each method, including the current one, has had
3304 flaws of various sorts. Here we lay out the different dependency
3305 tracking methods, their flaws, and their fixes. We conclude with
3306 recommendations for tool writers, and by indicating future directions
3307 for dependency tracking work in Automake.
3311 * First Take on Dependencies:: Precomputed dependency tracking
3312 * Dependencies As Side Effects:: Update at developer compile time
3313 * Dependencies for the User:: Update at user compile time
3314 * Techniques for Dependencies:: Alternative approaches
3315 * Recommendations for Tool Writers:: What tool writers can do to help
3316 * Future Directions for Dependencies:: Languages Automake does not know
3319 File: automake.info, Node: First Take on Dependencies, Next: Dependencies As Side Effects, Up: Dependency Tracking Evolution
3321 28.2.1 First Take on Dependency Tracking
3322 ----------------------------------------
3327 Our first attempt at automatic dependency tracking was based on the
3328 method recommended by GNU `make'. (*note Generating Prerequisites
3329 Automatically: (make)Automatic Prerequisites.)
3331 This version worked by precomputing dependencies ahead of time. For
3332 each source file, it had a special `.P' file that held the
3333 dependencies. There was a rule to generate a `.P' file by invoking the
3334 compiler appropriately. All such `.P' files were included by the
3335 `Makefile', thus implicitly becoming dependencies of `Makefile'.
3340 This approach had several critical bugs.
3342 * The code to generate the `.P' file relied on `gcc'. (A
3343 limitation, not technically a bug.)
3345 * The dependency tracking mechanism itself relied on GNU `make'. (A
3346 limitation, not technically a bug.)
3348 * Because each `.P' file was a dependency of `Makefile', this meant
3349 that dependency tracking was done eagerly by `make'. For
3350 instance, `make clean' would cause all the dependency files to be
3351 updated, and then immediately removed. This eagerness also caused
3352 problems with some configurations; if a certain source file could
3353 not be compiled on a given architecture for some reason,
3354 dependency tracking would fail, aborting the entire build.
3356 * As dependency tracking was done as a pre-pass, compile times were
3357 doubled-the compiler had to be run twice per source file.
3359 * `make dist' re-ran `automake' to generate a `Makefile' that did
3360 not have automatic dependency tracking (and that was thus portable
3361 to any version of `make'). In order to do this portably, Automake
3362 had to scan the dependency files and remove any reference that was
3363 to a source file not in the distribution. This process was
3364 error-prone. Also, if `make dist' was run in an environment where
3365 some object file had a dependency on a source file that was only
3366 conditionally created, Automake would generate a `Makefile' that
3367 referred to a file that might not appear in the end user's build.
3368 A special, hacky mechanism was required to work around this.
3373 The code generated by Automake is often inspired by the `Makefile'
3374 style of a particular author. In the case of the first implementation
3375 of dependency tracking, I believe the impetus and inspiration was Jim
3376 Meyering. (I could be mistaken. If you know otherwise feel free to
3380 File: automake.info, Node: Dependencies As Side Effects, Next: Dependencies for the User, Prev: First Take on Dependencies, Up: Dependency Tracking Evolution
3382 28.2.2 Dependencies As Side Effects
3383 -----------------------------------
3388 The next refinement of Automake's automatic dependency tracking scheme
3389 was to implement dependencies as side effects of the compilation. This
3390 was aimed at solving the most commonly reported problems with the first
3391 approach. In particular we were most concerned with eliminating the
3392 weird rebuilding effect associated with make clean.
3394 In this approach, the `.P' files were included using the `-include'
3395 command, which let us create these files lazily. This avoided the
3396 `make clean' problem.
3398 We only computed dependencies when a file was actually compiled.
3399 This avoided the performance penalty associated with scanning each file
3400 twice. It also let us avoid the other problems associated with the
3401 first, eager, implementation. For instance, dependencies would never
3402 be generated for a source file that was not compilable on a given
3403 architecture (because it in fact would never be compiled).
3408 * This approach also relied on the existence of `gcc' and GNU
3409 `make'. (A limitation, not technically a bug.)
3411 * Dependency tracking was still done by the developer, so the
3412 problems from the first implementation relating to massaging of
3413 dependencies by `make dist' were still in effect.
3415 * This implementation suffered from the "deleted header file"
3416 problem. Suppose a lazily-created `.P' file includes a dependency
3417 on a given header file, like this:
3419 maude.o: maude.c something.h
3421 Now suppose that the developer removes `something.h' and updates
3422 `maude.c' so that this include is no longer needed. If he runs
3423 `make', he will get an error because there is no way to create
3426 We fixed this problem in a later release by further massaging the
3427 output of `gcc' to include a dummy dependency for each header file.
3430 File: automake.info, Node: Dependencies for the User, Next: Techniques for Dependencies, Prev: Dependencies As Side Effects, Up: Dependency Tracking Evolution
3432 28.2.3 Dependencies for the User
3433 --------------------------------
3438 The bugs associated with `make dist', over time, became a real problem.
3439 Packages using Automake were being built on a large number of
3440 platforms, and were becoming increasingly complex. Broken dependencies
3441 were distributed in "portable" `Makefile.in's, leading to user
3442 complaints. Also, the requirement for `gcc' and GNU `make' was a
3443 constant source of bug reports. The next implementation of dependency
3444 tracking aimed to remove these problems.
3446 We realized that the only truly reliable way to automatically track
3447 dependencies was to do it when the package itself was built. This
3448 meant discovering a method portable to any version of make and any
3449 compiler. Also, we wanted to preserve what we saw as the best point of
3450 the second implementation: dependency computation as a side effect of
3453 In the end we found that most modern make implementations support
3454 some form of include directive. Also, we wrote a wrapper script that
3455 let us abstract away differences between dependency tracking methods for
3456 compilers. For instance, some compilers cannot generate dependencies
3457 as a side effect of compilation. In this case we simply have the
3458 script run the compiler twice. Currently our wrapper script
3459 (`depcomp') knows about twelve different compilers (including a
3460 "compiler" that simply invokes `makedepend' and then the real compiler,
3461 which is assumed to be a standard Unix-like C compiler with no way to
3462 do dependency tracking).
3467 * Running a wrapper script for each compilation slows down the build.
3469 * Many users don't really care about precise dependencies.
3471 * This implementation, like every other automatic dependency tracking
3472 scheme in common use today (indeed, every one we've ever heard of),
3473 suffers from the "duplicated new header" bug.
3475 This bug occurs because dependency tracking tools, such as the
3476 compiler, only generate dependencies on the successful opening of a
3477 file, and not on every probe.
3479 Suppose for instance that the compiler searches three directories
3480 for a given header, and that the header is found in the third
3481 directory. If the programmer erroneously adds a header file with
3482 the same name to the first directory, then a clean rebuild from
3483 scratch could fail (suppose the new header file is buggy), whereas
3484 an incremental rebuild will succeed.
3486 What has happened here is that people have a misunderstanding of
3487 what a dependency is. Tool writers think a dependency encodes
3488 information about which files were read by the compiler. However,
3489 a dependency must actually encode information about what the
3490 compiler tried to do.
3492 This problem is not serious in practice. Programmers typically do
3493 not use the same name for a header file twice in a given project.
3494 (At least, not in C or C++. This problem may be more troublesome
3495 in Java.) This problem is easy to fix, by modifying dependency
3496 generators to record every probe, instead of every successful open.
3498 * Since Automake generates dependencies as a side effect of
3499 compilation, there is a bootstrapping problem when header files
3500 are generated by running a program. The problem is that, the
3501 first time the build is done, there is no way by default to know
3502 that the headers are required, so make might try to run a
3503 compilation for which the headers have not yet been built.
3505 This was also a problem in the previous dependency tracking
3508 The current fix is to use `BUILT_SOURCES' to list built headers
3509 (*note Sources::). This causes them to be built before any other
3510 build rules are run. This is unsatisfactory as a general solution,
3511 however in practice it seems sufficient for most actual programs.
3513 This code is used since Automake 1.5.
3515 In GCC 3.0, we managed to convince the maintainers to add special
3516 command-line options to help Automake more efficiently do its job. We
3517 hoped this would let us avoid the use of a wrapper script when
3518 Automake's automatic dependency tracking was used with `gcc'.
3520 Unfortunately, this code doesn't quite do what we want. In
3521 particular, it removes the dependency file if the compilation fails;
3522 we'd prefer that it instead only touch the file in any way if the
3523 compilation succeeds.
3525 Nevertheless, since Automake 1.7, when a recent `gcc' is detected at
3526 `configure' time, we inline the dependency-generation code and do not
3527 use the `depcomp' wrapper script. This makes compilations faster for
3528 those using this compiler (probably our primary user base). The
3529 counterpart is that because we have to encode two compilation rules in
3530 `Makefile' (with or without `depcomp'), the produced `Makefile's are
3534 File: automake.info, Node: Techniques for Dependencies, Next: Recommendations for Tool Writers, Prev: Dependencies for the User, Up: Dependency Tracking Evolution
3536 28.2.4 Techniques for Computing Dependencies
3537 --------------------------------------------
3539 There are actually several ways for a build tool like Automake to cause
3540 tools to generate dependencies.
3543 This was a commonly-used method in the past. The idea is to run a
3544 special program over the source and have it generate dependency
3545 information. Traditional implementations of `makedepend' are not
3546 completely precise; ordinarily they were conservative and
3547 discovered too many dependencies.
3550 An obvious way to generate dependencies is to simply write the
3551 tool so that it can generate the information needed by the build
3552 tool. This is also the most portable method. Many compilers have
3553 an option to generate dependencies. Unfortunately, not all tools
3554 provide such an option.
3557 It is possible to write a special file system that tracks opens,
3558 reads, writes, etc, and then feed this information back to the
3559 build tool. `clearmake' does this. This is a very powerful
3560 technique, as it doesn't require cooperation from the tool.
3561 Unfortunately it is also very difficult to implement and also not
3562 practical in the general case.
3565 Rather than use the file system, one could write a special library
3566 to intercept `open' and other syscalls. This technique is also
3567 quite powerful, but unfortunately it is not portable enough for
3571 File: automake.info, Node: Recommendations for Tool Writers, Next: Future Directions for Dependencies, Prev: Techniques for Dependencies, Up: Dependency Tracking Evolution
3573 28.2.5 Recommendations for Tool Writers
3574 ---------------------------------------
3576 We think that every compilation tool ought to be able to generate
3577 dependencies as a side effect of compilation. Furthermore, at least
3578 while `make'-based tools are nearly universally in use (at least in the
3579 free software community), the tool itself should generate dummy
3580 dependencies for header files, to avoid the deleted header file bug.
3581 Finally, the tool should generate a dependency for each probe, instead
3582 of each successful file open, in order to avoid the duplicated new
3586 File: automake.info, Node: Future Directions for Dependencies, Prev: Recommendations for Tool Writers, Up: Dependency Tracking Evolution
3588 28.2.6 Future Directions for Dependencies
3589 -----------------------------------------
3591 Currently, only languages and compilers understood by Automake can have
3592 dependency tracking enabled. We would like to see if it is practical
3593 (and worthwhile) to let this support be extended by the user to
3594 languages unknown to Automake.
3597 File: automake.info, Node: Releases, Prev: Dependency Tracking Evolution, Up: History
3599 28.3 Release Statistics
3600 =======================
3602 The following table (inspired by `perlhist(1)') quantifies the
3603 evolution of Automake using these metrics:
3606 The date and version of the release.
3609 The number of lines of the `automake' script.
3612 The number of lines of the `aclocal' script.
3615 The number of lines of the `Perl' supporting modules.
3618 The number of lines of the `Makefile' fragments. The number in
3619 parentheses is the number of files.
3622 The number of lines (and files) of Autoconf macros.
3625 The number of pages of the documentation (the Postscript version).
3628 The number of test cases in the test suite. Of those, the number
3629 in parentheses is the number of generated test cases.
3631 Date Rel am acl pm `*.am' m4 doc t
3632 ------------------------------------------------------------------------------------
3633 1994-09-19 CVS 141 299 (24)
3634 1994-11-05 CVS 208 332 (28)
3635 1995-11-23 0.20 533 458 (35) 9
3636 1995-11-26 0.21 613 480 (36) 11
3637 1995-11-28 0.22 1116 539 (38) 12
3638 1995-11-29 0.23 1240 541 (38) 12
3639 1995-12-08 0.24 1462 504 (33) 14
3640 1995-12-10 0.25 1513 511 (37) 15
3641 1996-01-03 0.26 1706 438 (36) 16
3642 1996-01-03 0.27 1706 438 (36) 16
3643 1996-01-13 0.28 1964 934 (33) 16
3644 1996-02-07 0.29 2299 936 (33) 17
3645 1996-02-24 0.30 2544 919 (32) 85 (1) 20 9
3646 1996-03-11 0.31 2877 919 (32) 85 (1) 29 17
3647 1996-04-27 0.32 3058 921 (31) 85 (1) 30 26
3648 1996-05-18 0.33 3110 926 (31) 105 (1) 30 35
3649 1996-05-28 1.0 3134 973 (32) 105 (1) 30 38
3650 1997-06-22 1.2 6089 385 1294 (36) 592 (20) 37 126
3651 1998-04-05 1.3 6415 422 1470 (39) 741 (23) 39 156
3652 1999-01-14 1.4 7240 426 1591 (40) 734 (20) 51 197
3653 2001-05-08 1.4-p1 7251 426 1591 (40) 734 (20) 51 197
3654 2001-05-24 1.4-p2 7268 439 1591 (40) 734 (20) 49 197
3655 2001-06-07 1.4-p3 7312 439 1591 (40) 734 (20) 49 197
3656 2001-06-10 1.4-p4 7321 439 1591 (40) 734 (20) 49 198
3657 2001-07-15 1.4-p5 7228 426 1596 (40) 734 (20) 51 198
3658 2001-08-23 1.5 8016 475 600 2654 (39) 1166 (29) 63 327
3659 2002-03-05 1.6 8465 475 1136 2732 (39) 1603 (27) 66 365
3660 2002-04-11 1.6.1 8544 475 1136 2741 (39) 1603 (27) 66 372
3661 2002-06-14 1.6.2 8575 475 1136 2800 (39) 1609 (27) 67 386
3662 2002-07-28 1.6.3 8600 475 1153 2809 (39) 1609 (27) 67 391
3663 2002-07-28 1.4-p6 7332 455 1596 (40) 735 (20) 49 197
3664 2002-09-25 1.7 9189 471 1790 2965 (39) 1606 (28) 73 430
3665 2002-10-16 1.7.1 9229 475 1790 2977 (39) 1606 (28) 73 437
3666 2002-12-06 1.7.2 9334 475 1790 2988 (39) 1606 (28) 77 445
3667 2003-02-20 1.7.3 9389 475 1790 3023 (39) 1651 (29) 84 448
3668 2003-04-23 1.7.4 9429 475 1790 3031 (39) 1644 (29) 85 458
3669 2003-05-18 1.7.5 9429 475 1790 3033 (39) 1645 (29) 85 459
3670 2003-07-10 1.7.6 9442 475 1790 3033 (39) 1660 (29) 85 461
3671 2003-09-07 1.7.7 9443 475 1790 3041 (39) 1660 (29) 90 467
3672 2003-10-07 1.7.8 9444 475 1790 3041 (39) 1660 (29) 90 468
3673 2003-11-09 1.7.9 9444 475 1790 3048 (39) 1660 (29) 90 468
3674 2003-12-10 1.8 7171 585 7730 3236 (39) 1666 (31) 104 521
3675 2004-01-11 1.8.1 7217 663 7726 3287 (39) 1686 (31) 104 525
3676 2004-01-12 1.8.2 7217 663 7726 3288 (39) 1686 (31) 104 526
3677 2004-03-07 1.8.3 7214 686 7735 3303 (39) 1695 (31) 111 530
3678 2004-04-25 1.8.4 7214 686 7736 3310 (39) 1701 (31) 112 531
3679 2004-05-16 1.8.5 7240 686 7736 3299 (39) 1701 (31) 112 533
3680 2004-07-28 1.9 7508 715 7794 3352 (40) 1812 (32) 115 551
3681 2004-08-11 1.9.1 7512 715 7794 3354 (40) 1812 (32) 115 552
3682 2004-09-19 1.9.2 7512 715 7794 3354 (40) 1812 (32) 132 554
3683 2004-11-01 1.9.3 7507 718 7804 3354 (40) 1812 (32) 134 556
3684 2004-12-18 1.9.4 7508 718 7856 3361 (40) 1811 (32) 140 560
3685 2005-02-13 1.9.5 7523 719 7859 3373 (40) 1453 (32) 142 562
3686 2005-07-10 1.9.6 7539 699 7867 3400 (40) 1453 (32) 144 570
3687 2006-10-15 1.10 7859 1072 8024 3512 (40) 1496 (34) 172 604
3688 2008-01-19 1.10.1 7870 1089 8025 3520 (40) 1499 (34) 173 617
3689 2008-11-23 1.10.2 7882 1089 8027 3540 (40) 1509 (34) 176 628
3690 2009-05-17 1.11 8721 1092 8289 4164 (42) 1714 (37) 181 732 (20)
3691 2009-12-07 1.10.3 7892 1089 8027 3566 (40) 1535 (34) 174 636
3692 2009-12-07 1.11.1 8722 1092 8292 4162 (42) 1730 (37) 181 739 (20)
3695 File: automake.info, Node: Copying This Manual, Next: Indices, Prev: History, Up: Top
3697 Anhang A Copying This Manual
3698 ****************************
3702 * GNU Free Documentation License:: License for copying this manual
3705 File: automake.info, Node: GNU Free Documentation License, Up: Copying This Manual
3707 A.1 GNU Free Documentation License
3708 ==================================
3710 Version 1.3, 3 November 2008
3712 Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
3715 Everyone is permitted to copy and distribute verbatim copies
3716 of this license document, but changing it is not allowed.
3720 The purpose of this License is to make a manual, textbook, or other
3721 functional and useful document "free" in the sense of freedom: to
3722 assure everyone the effective freedom to copy and redistribute it,
3723 with or without modifying it, either commercially or
3724 noncommercially. Secondarily, this License preserves for the
3725 author and publisher a way to get credit for their work, while not
3726 being considered responsible for modifications made by others.
3728 This License is a kind of "copyleft", which means that derivative
3729 works of the document must themselves be free in the same sense.
3730 It complements the GNU General Public License, which is a copyleft
3731 license designed for free software.
3733 We have designed this License in order to use it for manuals for
3734 free software, because free software needs free documentation: a
3735 free program should come with manuals providing the same freedoms
3736 that the software does. But this License is not limited to
3737 software manuals; it can be used for any textual work, regardless
3738 of subject matter or whether it is published as a printed book.
3739 We recommend this License principally for works whose purpose is
3740 instruction or reference.
3742 1. APPLICABILITY AND DEFINITIONS
3744 This License applies to any manual or other work, in any medium,
3745 that contains a notice placed by the copyright holder saying it
3746 can be distributed under the terms of this License. Such a notice
3747 grants a world-wide, royalty-free license, unlimited in duration,
3748 to use that work under the conditions stated herein. The
3749 "Document", below, refers to any such manual or work. Any member
3750 of the public is a licensee, and is addressed as "you". You
3751 accept the license if you copy, modify or distribute the work in a
3752 way requiring permission under copyright law.
3754 A "Modified Version" of the Document means any work containing the
3755 Document or a portion of it, either copied verbatim, or with
3756 modifications and/or translated into another language.
3758 A "Secondary Section" is a named appendix or a front-matter section
3759 of the Document that deals exclusively with the relationship of the
3760 publishers or authors of the Document to the Document's overall
3761 subject (or to related matters) and contains nothing that could
3762 fall directly within that overall subject. (Thus, if the Document
3763 is in part a textbook of mathematics, a Secondary Section may not
3764 explain any mathematics.) The relationship could be a matter of
3765 historical connection with the subject or with related matters, or
3766 of legal, commercial, philosophical, ethical or political position
3769 The "Invariant Sections" are certain Secondary Sections whose
3770 titles are designated, as being those of Invariant Sections, in
3771 the notice that says that the Document is released under this
3772 License. If a section does not fit the above definition of
3773 Secondary then it is not allowed to be designated as Invariant.
3774 The Document may contain zero Invariant Sections. If the Document
3775 does not identify any Invariant Sections then there are none.
3777 The "Cover Texts" are certain short passages of text that are
3778 listed, as Front-Cover Texts or Back-Cover Texts, in the notice
3779 that says that the Document is released under this License. A
3780 Front-Cover Text may be at most 5 words, and a Back-Cover Text may
3781 be at most 25 words.
3783 A "Transparent" copy of the Document means a machine-readable copy,
3784 represented in a format whose specification is available to the
3785 general public, that is suitable for revising the document
3786 straightforwardly with generic text editors or (for images
3787 composed of pixels) generic paint programs or (for drawings) some
3788 widely available drawing editor, and that is suitable for input to
3789 text formatters or for automatic translation to a variety of
3790 formats suitable for input to text formatters. A copy made in an
3791 otherwise Transparent file format whose markup, or absence of
3792 markup, has been arranged to thwart or discourage subsequent
3793 modification by readers is not Transparent. An image format is
3794 not Transparent if used for any substantial amount of text. A
3795 copy that is not "Transparent" is called "Opaque".
3797 Examples of suitable formats for Transparent copies include plain
3798 ASCII without markup, Texinfo input format, LaTeX input format,
3799 SGML or XML using a publicly available DTD, and
3800 standard-conforming simple HTML, PostScript or PDF designed for
3801 human modification. Examples of transparent image formats include
3802 PNG, XCF and JPG. Opaque formats include proprietary formats that
3803 can be read and edited only by proprietary word processors, SGML or
3804 XML for which the DTD and/or processing tools are not generally
3805 available, and the machine-generated HTML, PostScript or PDF
3806 produced by some word processors for output purposes only.
3808 The "Title Page" means, for a printed book, the title page itself,
3809 plus such following pages as are needed to hold, legibly, the
3810 material this License requires to appear in the title page. For
3811 works in formats which do not have any title page as such, "Title
3812 Page" means the text near the most prominent appearance of the
3813 work's title, preceding the beginning of the body of the text.
3815 The "publisher" means any person or entity that distributes copies
3816 of the Document to the public.
3818 A section "Entitled XYZ" means a named subunit of the Document
3819 whose title either is precisely XYZ or contains XYZ in parentheses
3820 following text that translates XYZ in another language. (Here XYZ
3821 stands for a specific section name mentioned below, such as
3822 "Acknowledgements", "Dedications", "Endorsements", or "History".)
3823 To "Preserve the Title" of such a section when you modify the
3824 Document means that it remains a section "Entitled XYZ" according
3827 The Document may include Warranty Disclaimers next to the notice
3828 which states that this License applies to the Document. These
3829 Warranty Disclaimers are considered to be included by reference in
3830 this License, but only as regards disclaiming warranties: any other
3831 implication that these Warranty Disclaimers may have is void and
3832 has no effect on the meaning of this License.
3836 You may copy and distribute the Document in any medium, either
3837 commercially or noncommercially, provided that this License, the
3838 copyright notices, and the license notice saying this License
3839 applies to the Document are reproduced in all copies, and that you
3840 add no other conditions whatsoever to those of this License. You
3841 may not use technical measures to obstruct or control the reading
3842 or further copying of the copies you make or distribute. However,
3843 you may accept compensation in exchange for copies. If you
3844 distribute a large enough number of copies you must also follow
3845 the conditions in section 3.
3847 You may also lend copies, under the same conditions stated above,
3848 and you may publicly display copies.
3850 3. COPYING IN QUANTITY
3852 If you publish printed copies (or copies in media that commonly
3853 have printed covers) of the Document, numbering more than 100, and
3854 the Document's license notice requires Cover Texts, you must
3855 enclose the copies in covers that carry, clearly and legibly, all
3856 these Cover Texts: Front-Cover Texts on the front cover, and
3857 Back-Cover Texts on the back cover. Both covers must also clearly
3858 and legibly identify you as the publisher of these copies. The
3859 front cover must present the full title with all words of the
3860 title equally prominent and visible. You may add other material
3861 on the covers in addition. Copying with changes limited to the
3862 covers, as long as they preserve the title of the Document and
3863 satisfy these conditions, can be treated as verbatim copying in
3866 If the required texts for either cover are too voluminous to fit
3867 legibly, you should put the first ones listed (as many as fit
3868 reasonably) on the actual cover, and continue the rest onto
3871 If you publish or distribute Opaque copies of the Document
3872 numbering more than 100, you must either include a
3873 machine-readable Transparent copy along with each Opaque copy, or
3874 state in or with each Opaque copy a computer-network location from
3875 which the general network-using public has access to download
3876 using public-standard network protocols a complete Transparent
3877 copy of the Document, free of added material. If you use the
3878 latter option, you must take reasonably prudent steps, when you
3879 begin distribution of Opaque copies in quantity, to ensure that
3880 this Transparent copy will remain thus accessible at the stated
3881 location until at least one year after the last time you
3882 distribute an Opaque copy (directly or through your agents or
3883 retailers) of that edition to the public.
3885 It is requested, but not required, that you contact the authors of
3886 the Document well before redistributing any large number of
3887 copies, to give them a chance to provide you with an updated
3888 version of the Document.
3892 You may copy and distribute a Modified Version of the Document
3893 under the conditions of sections 2 and 3 above, provided that you
3894 release the Modified Version under precisely this License, with
3895 the Modified Version filling the role of the Document, thus
3896 licensing distribution and modification of the Modified Version to
3897 whoever possesses a copy of it. In addition, you must do these
3898 things in the Modified Version:
3900 A. Use in the Title Page (and on the covers, if any) a title
3901 distinct from that of the Document, and from those of
3902 previous versions (which should, if there were any, be listed
3903 in the History section of the Document). You may use the
3904 same title as a previous version if the original publisher of
3905 that version gives permission.
3907 B. List on the Title Page, as authors, one or more persons or
3908 entities responsible for authorship of the modifications in
3909 the Modified Version, together with at least five of the
3910 principal authors of the Document (all of its principal
3911 authors, if it has fewer than five), unless they release you
3912 from this requirement.
3914 C. State on the Title page the name of the publisher of the
3915 Modified Version, as the publisher.
3917 D. Preserve all the copyright notices of the Document.
3919 E. Add an appropriate copyright notice for your modifications
3920 adjacent to the other copyright notices.
3922 F. Include, immediately after the copyright notices, a license
3923 notice giving the public permission to use the Modified
3924 Version under the terms of this License, in the form shown in
3927 G. Preserve in that license notice the full lists of Invariant
3928 Sections and required Cover Texts given in the Document's
3931 H. Include an unaltered copy of this License.
3933 I. Preserve the section Entitled "History", Preserve its Title,
3934 and add to it an item stating at least the title, year, new
3935 authors, and publisher of the Modified Version as given on
3936 the Title Page. If there is no section Entitled "History" in
3937 the Document, create one stating the title, year, authors,
3938 and publisher of the Document as given on its Title Page,
3939 then add an item describing the Modified Version as stated in
3940 the previous sentence.
3942 J. Preserve the network location, if any, given in the Document
3943 for public access to a Transparent copy of the Document, and
3944 likewise the network locations given in the Document for
3945 previous versions it was based on. These may be placed in
3946 the "History" section. You may omit a network location for a
3947 work that was published at least four years before the
3948 Document itself, or if the original publisher of the version
3949 it refers to gives permission.
3951 K. For any section Entitled "Acknowledgements" or "Dedications",
3952 Preserve the Title of the section, and preserve in the
3953 section all the substance and tone of each of the contributor
3954 acknowledgements and/or dedications given therein.
3956 L. Preserve all the Invariant Sections of the Document,
3957 unaltered in their text and in their titles. Section numbers
3958 or the equivalent are not considered part of the section
3961 M. Delete any section Entitled "Endorsements". Such a section
3962 may not be included in the Modified Version.
3964 N. Do not retitle any existing section to be Entitled
3965 "Endorsements" or to conflict in title with any Invariant
3968 O. Preserve any Warranty Disclaimers.
3970 If the Modified Version includes new front-matter sections or
3971 appendices that qualify as Secondary Sections and contain no
3972 material copied from the Document, you may at your option
3973 designate some or all of these sections as invariant. To do this,
3974 add their titles to the list of Invariant Sections in the Modified
3975 Version's license notice. These titles must be distinct from any
3976 other section titles.
3978 You may add a section Entitled "Endorsements", provided it contains
3979 nothing but endorsements of your Modified Version by various
3980 parties--for example, statements of peer review or that the text
3981 has been approved by an organization as the authoritative
3982 definition of a standard.
3984 You may add a passage of up to five words as a Front-Cover Text,
3985 and a passage of up to 25 words as a Back-Cover Text, to the end
3986 of the list of Cover Texts in the Modified Version. Only one
3987 passage of Front-Cover Text and one of Back-Cover Text may be
3988 added by (or through arrangements made by) any one entity. If the
3989 Document already includes a cover text for the same cover,
3990 previously added by you or by arrangement made by the same entity
3991 you are acting on behalf of, you may not add another; but you may
3992 replace the old one, on explicit permission from the previous
3993 publisher that added the old one.
3995 The author(s) and publisher(s) of the Document do not by this
3996 License give permission to use their names for publicity for or to
3997 assert or imply endorsement of any Modified Version.
3999 5. COMBINING DOCUMENTS
4001 You may combine the Document with other documents released under
4002 this License, under the terms defined in section 4 above for
4003 modified versions, provided that you include in the combination
4004 all of the Invariant Sections of all of the original documents,
4005 unmodified, and list them all as Invariant Sections of your
4006 combined work in its license notice, and that you preserve all
4007 their Warranty Disclaimers.
4009 The combined work need only contain one copy of this License, and
4010 multiple identical Invariant Sections may be replaced with a single
4011 copy. If there are multiple Invariant Sections with the same name
4012 but different contents, make the title of each such section unique
4013 by adding at the end of it, in parentheses, the name of the
4014 original author or publisher of that section if known, or else a
4015 unique number. Make the same adjustment to the section titles in
4016 the list of Invariant Sections in the license notice of the
4019 In the combination, you must combine any sections Entitled
4020 "History" in the various original documents, forming one section
4021 Entitled "History"; likewise combine any sections Entitled
4022 "Acknowledgements", and any sections Entitled "Dedications". You
4023 must delete all sections Entitled "Endorsements."
4025 6. COLLECTIONS OF DOCUMENTS
4027 You may make a collection consisting of the Document and other
4028 documents released under this License, and replace the individual
4029 copies of this License in the various documents with a single copy
4030 that is included in the collection, provided that you follow the
4031 rules of this License for verbatim copying of each of the
4032 documents in all other respects.
4034 You may extract a single document from such a collection, and
4035 distribute it individually under this License, provided you insert
4036 a copy of this License into the extracted document, and follow
4037 this License in all other respects regarding verbatim copying of
4040 7. AGGREGATION WITH INDEPENDENT WORKS
4042 A compilation of the Document or its derivatives with other
4043 separate and independent documents or works, in or on a volume of
4044 a storage or distribution medium, is called an "aggregate" if the
4045 copyright resulting from the compilation is not used to limit the
4046 legal rights of the compilation's users beyond what the individual
4047 works permit. When the Document is included in an aggregate, this
4048 License does not apply to the other works in the aggregate which
4049 are not themselves derivative works of the Document.
4051 If the Cover Text requirement of section 3 is applicable to these
4052 copies of the Document, then if the Document is less than one half
4053 of the entire aggregate, the Document's Cover Texts may be placed
4054 on covers that bracket the Document within the aggregate, or the
4055 electronic equivalent of covers if the Document is in electronic
4056 form. Otherwise they must appear on printed covers that bracket
4057 the whole aggregate.
4061 Translation is considered a kind of modification, so you may
4062 distribute translations of the Document under the terms of section
4063 4. Replacing Invariant Sections with translations requires special
4064 permission from their copyright holders, but you may include
4065 translations of some or all Invariant Sections in addition to the
4066 original versions of these Invariant Sections. You may include a
4067 translation of this License, and all the license notices in the
4068 Document, and any Warranty Disclaimers, provided that you also
4069 include the original English version of this License and the
4070 original versions of those notices and disclaimers. In case of a
4071 disagreement between the translation and the original version of
4072 this License or a notice or disclaimer, the original version will
4075 If a section in the Document is Entitled "Acknowledgements",
4076 "Dedications", or "History", the requirement (section 4) to
4077 Preserve its Title (section 1) will typically require changing the
4082 You may not copy, modify, sublicense, or distribute the Document
4083 except as expressly provided under this License. Any attempt
4084 otherwise to copy, modify, sublicense, or distribute it is void,
4085 and will automatically terminate your rights under this License.
4087 However, if you cease all violation of this License, then your
4088 license from a particular copyright holder is reinstated (a)
4089 provisionally, unless and until the copyright holder explicitly
4090 and finally terminates your license, and (b) permanently, if the
4091 copyright holder fails to notify you of the violation by some
4092 reasonable means prior to 60 days after the cessation.
4094 Moreover, your license from a particular copyright holder is
4095 reinstated permanently if the copyright holder notifies you of the
4096 violation by some reasonable means, this is the first time you have
4097 received notice of violation of this License (for any work) from
4098 that copyright holder, and you cure the violation prior to 30 days
4099 after your receipt of the notice.
4101 Termination of your rights under this section does not terminate
4102 the licenses of parties who have received copies or rights from
4103 you under this License. If your rights have been terminated and
4104 not permanently reinstated, receipt of a copy of some or all of
4105 the same material does not give you any rights to use it.
4107 10. FUTURE REVISIONS OF THIS LICENSE
4109 The Free Software Foundation may publish new, revised versions of
4110 the GNU Free Documentation License from time to time. Such new
4111 versions will be similar in spirit to the present version, but may
4112 differ in detail to address new problems or concerns. See
4113 `http://www.gnu.org/copyleft/'.
4115 Each version of the License is given a distinguishing version
4116 number. If the Document specifies that a particular numbered
4117 version of this License "or any later version" applies to it, you
4118 have the option of following the terms and conditions either of
4119 that specified version or of any later version that has been
4120 published (not as a draft) by the Free Software Foundation. If
4121 the Document does not specify a version number of this License,
4122 you may choose any version ever published (not as a draft) by the
4123 Free Software Foundation. If the Document specifies that a proxy
4124 can decide which future versions of this License can be used, that
4125 proxy's public statement of acceptance of a version permanently
4126 authorizes you to choose that version for the Document.
4130 "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
4131 World Wide Web server that publishes copyrightable works and also
4132 provides prominent facilities for anybody to edit those works. A
4133 public wiki that anybody can edit is an example of such a server.
4134 A "Massive Multiauthor Collaboration" (or "MMC") contained in the
4135 site means any set of copyrightable works thus published on the MMC
4138 "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
4139 license published by Creative Commons Corporation, a not-for-profit
4140 corporation with a principal place of business in San Francisco,
4141 California, as well as future copyleft versions of that license
4142 published by that same organization.
4144 "Incorporate" means to publish or republish a Document, in whole or
4145 in part, as part of another Document.
4147 An MMC is "eligible for relicensing" if it is licensed under this
4148 License, and if all works that were first published under this
4149 License somewhere other than this MMC, and subsequently
4150 incorporated in whole or in part into the MMC, (1) had no cover
4151 texts or invariant sections, and (2) were thus incorporated prior
4152 to November 1, 2008.
4154 The operator of an MMC Site may republish an MMC contained in the
4155 site under CC-BY-SA on the same site at any time before August 1,
4156 2009, provided the MMC is eligible for relicensing.
4159 ADDENDUM: How to use this License for your documents
4160 ====================================================
4162 To use this License in a document you have written, include a copy of
4163 the License in the document and put the following copyright and license
4164 notices just after the title page:
4166 Copyright (C) YEAR YOUR NAME.
4167 Permission is granted to copy, distribute and/or modify this document
4168 under the terms of the GNU Free Documentation License, Version 1.3
4169 or any later version published by the Free Software Foundation;
4170 with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
4171 Texts. A copy of the license is included in the section entitled ``GNU
4172 Free Documentation License''.
4174 If you have Invariant Sections, Front-Cover Texts and Back-Cover
4175 Texts, replace the "with...Texts." line with this:
4177 with the Invariant Sections being LIST THEIR TITLES, with
4178 the Front-Cover Texts being LIST, and with the Back-Cover Texts
4181 If you have Invariant Sections without Cover Texts, or some other
4182 combination of the three, merge those two alternatives to suit the
4185 If your document contains nontrivial examples of program code, we
4186 recommend releasing these examples in parallel under your choice of
4187 free software license, such as the GNU General Public License, to
4188 permit their use in free software.
4191 File: automake.info, Node: Indices, Prev: Copying This Manual, Up: Top
4198 * Macro Index:: Index of Autoconf macros
4199 * Variable Index:: Index of Makefile variables
4200 * General Index:: General index
4203 File: automake.info, Node: Macro Index, Next: Variable Index, Up: Indices
4211 * _AM_DEPENDENCIES: Private Macros. (line 12)
4212 * AC_CANONICAL_BUILD: Optional. (line 11)
4213 * AC_CANONICAL_HOST: Optional. (line 12)
4214 * AC_CANONICAL_TARGET: Optional. (line 13)
4215 * AC_CONFIG_AUX_DIR <1>: Subpackages. (line 6)
4216 * AC_CONFIG_AUX_DIR: Optional. (line 19)
4217 * AC_CONFIG_FILES: Requirements. (line 15)
4218 * AC_CONFIG_HEADERS: Optional. (line 46)
4219 * AC_CONFIG_LIBOBJ_DIR <1>: LIBOBJS. (line 50)
4220 * AC_CONFIG_LIBOBJ_DIR: Optional. (line 41)
4221 * AC_CONFIG_LINKS: Optional. (line 55)
4222 * AC_CONFIG_SUBDIRS: Subpackages. (line 6)
4223 * AC_DEFUN: Extending aclocal. (line 33)
4224 * AC_F77_LIBRARY_LDFLAGS: Optional. (line 98)
4225 * AC_FC_SRCEXT: Optional. (line 104)
4226 * AC_INIT: Public Macros. (line 25)
4227 * AC_LIBOBJ <1>: LIBOBJS. (line 11)
4228 * AC_LIBOBJ <2>: LTLIBOBJS. (line 6)
4229 * AC_LIBOBJ: Optional. (line 65)
4230 * AC_LIBSOURCE <1>: LIBOBJS. (line 17)
4231 * AC_LIBSOURCE: Optional. (line 66)
4232 * AC_LIBSOURCES: Optional. (line 67)
4233 * AC_OUTPUT: Requirements. (line 15)
4234 * AC_PREREQ: Extending aclocal. (line 33)
4235 * AC_PROG_CC_C_O: Public Macros. (line 80)
4236 * AC_PROG_CXX: Optional. (line 85)
4237 * AC_PROG_F77: Optional. (line 93)
4238 * AC_PROG_FC: Optional. (line 109)
4239 * AC_PROG_LEX <1>: Public Macros. (line 86)
4240 * AC_PROG_LEX: Optional. (line 124)
4241 * AC_PROG_LIBTOOL: Optional. (line 114)
4242 * AC_PROG_OBJC: Optional. (line 89)
4243 * AC_PROG_RANLIB: Optional. (line 81)
4244 * AC_PROG_YACC: Optional. (line 118)
4245 * AC_REQUIRE_AUX_FILE: Optional. (line 128)
4246 * AC_SUBST: Optional. (line 137)
4247 * AM_C_PROTOTYPES <1>: ANSI. (line 34)
4248 * AM_C_PROTOTYPES <2>: Obsolete Macros. (line 13)
4249 * AM_C_PROTOTYPES: Optional. (line 150)
4250 * AM_COND_IF <1>: Usage of Conditionals.
4252 * AM_COND_IF: Optional. (line 157)
4253 * AM_CONDITIONAL <1>: Usage of Conditionals.
4255 * AM_CONDITIONAL: Optional. (line 154)
4256 * AM_CONFIG_HEADER: Obsolete Macros. (line 20)
4257 * AM_DEP_TRACK: Private Macros. (line 14)
4258 * AM_ENABLE_MULTILIB: Public Macros. (line 7)
4259 * AM_GNU_GETTEXT: Optional. (line 163)
4260 * AM_GNU_GETTEXT_INTL_SUBDIR: Optional. (line 169)
4261 * AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL: Obsolete Macros. (line 25)
4262 * AM_INIT_AUTOMAKE <1>: Public Macros. (line 16)
4263 * AM_INIT_AUTOMAKE: Requirements. (line 6)
4264 * AM_MAINTAINER_MODE <1>: maintainer-mode. (line 36)
4265 * AM_MAINTAINER_MODE: Rebuilding. (line 9)
4266 * AM_MAINTAINER_MODE([DEFAULT-MODE]): Optional. (line 174)
4267 * AM_MAKE_INCLUDE: Private Macros. (line 20)
4268 * AM_OUTPUT_DEPENDENCY_COMMANDS: Private Macros. (line 15)
4269 * AM_PATH_LISPDIR: Public Macros. (line 60)
4270 * AM_PATH_PYTHON: Python. (line 30)
4271 * AM_PROG_AS: Public Macros. (line 75)
4272 * AM_PROG_CC_C_O: Public Macros. (line 80)
4273 * AM_PROG_GCJ: Public Macros. (line 91)
4274 * AM_PROG_INSTALL_STRIP: Private Macros. (line 25)
4275 * AM_PROG_LEX: Public Macros. (line 86)
4276 * AM_PROG_MKDIR_P: Obsolete Macros. (line 31)
4277 * AM_PROG_UPC: Public Macros. (line 96)
4278 * AM_PROG_VALAC: Vala Support. (line 21)
4279 * AM_SANITY_CHECK: Private Macros. (line 30)
4280 * AM_SET_DEPDIR: Private Macros. (line 13)
4281 * AM_SILENT_RULES: Public Macros. (line 102)
4282 * AM_SUBST_NOTMAKE(VAR): Optional. (line 182)
4283 * AM_SYS_POSIX_TERMIOS: Obsolete Macros. (line 53)
4284 * AM_WITH_DMALLOC: Public Macros. (line 106)
4285 * AM_WITH_REGEX: Public Macros. (line 111)
4286 * m4_include <1>: Basics of Distribution.
4288 * m4_include: Optional. (line 192)
4291 File: automake.info, Node: Variable Index, Next: General Index, Prev: Macro Index, Up: Indices
4299 * _DATA: Data. (line 6)
4300 * _HEADERS: Headers. (line 6)
4301 * _LIBRARIES: A Library. (line 6)
4302 * _LISP: Emacs Lisp. (line 6)
4303 * _LOG_COMPILE: Simple Tests using parallel-tests.
4305 * _LOG_COMPILER: Simple Tests using parallel-tests.
4307 * _LOG_FLAGS: Simple Tests using parallel-tests.
4309 * _LTLIBRARIES: Libtool Libraries. (line 6)
4310 * _MANS: Man Pages. (line 6)
4311 * _PROGRAMS <1>: Program Sources. (line 6)
4312 * _PROGRAMS: Uniform. (line 11)
4313 * _PYTHON: Python. (line 6)
4314 * _SCRIPTS: Scripts. (line 6)
4315 * _SOURCES <1>: Default _SOURCES. (line 6)
4316 * _SOURCES: Program Sources. (line 32)
4317 * _TEXINFOS: Texinfo. (line 6)
4318 * ACLOCAL_AMFLAGS <1>: Rebuilding. (line 12)
4319 * ACLOCAL_AMFLAGS: Local Macros. (line 19)
4320 * ALLOCA <1>: LIBOBJS. (line 6)
4321 * ALLOCA: LTLIBOBJS. (line 6)
4322 * AM_CCASFLAGS: Assembly Support. (line 10)
4323 * AM_CFLAGS: Program Variables. (line 39)
4324 * AM_COLOR_TESTS: Simple Tests. (line 25)
4325 * AM_CPPFLAGS <1>: Assembly Support. (line 10)
4326 * AM_CPPFLAGS: Program Variables. (line 16)
4327 * AM_CXXFLAGS: C++ Support. (line 22)
4328 * AM_DEFAULT_SOURCE_EXT: Default _SOURCES. (line 6)
4329 * AM_DEFAULT_VERBOSITY: Options. (line 180)
4330 * AM_ETAGSFLAGS: Tags. (line 25)
4331 * AM_EXT_LOG_FLAGS: Simple Tests using parallel-tests.
4333 * AM_FCFLAGS: Fortran 9x Support. (line 22)
4334 * AM_FFLAGS: Fortran 77 Support. (line 22)
4335 * AM_GCJFLAGS: Java Support. (line 24)
4336 * AM_INSTALLCHECK_STD_OPTIONS_EXEMPT: Options. (line 205)
4337 * AM_JAVACFLAGS: Java. (line 36)
4338 * AM_LDFLAGS <1>: Program Variables. (line 49)
4339 * AM_LDFLAGS: Linking. (line 10)
4340 * AM_LFLAGS: Yacc and Lex. (line 56)
4341 * AM_LIBTOOLFLAGS: Libtool Flags. (line 6)
4342 * AM_LOG_FLAGS: Simple Tests using parallel-tests.
4344 * AM_MAKEFLAGS: Subdirectories. (line 29)
4345 * AM_MAKEINFOFLAGS: Texinfo. (line 104)
4346 * AM_MAKEINFOHTMLFLAGS: Texinfo. (line 105)
4347 * AM_OBJCFLAGS: Objective C Support. (line 22)
4348 * AM_RFLAGS: Fortran 77 Support. (line 28)
4349 * AM_RUNTESTFLAGS: DejaGnu Tests. (line 24)
4350 * AM_UPCFLAGS: Unified Parallel C Support.
4352 * AM_V_at: Options. (line 180)
4353 * AM_V_GEN: Options. (line 180)
4354 * AM_VALAFLAGS: Vala Support. (line 35)
4355 * AM_YFLAGS: Yacc and Lex. (line 33)
4356 * ANSI2KNR: Obsolete Macros. (line 13)
4357 * AUTOCONF: Invoking Automake. (line 28)
4358 * AUTOM4TE: Invoking aclocal. (line 45)
4359 * AUTOMAKE_JOBS: Invoking Automake. (line 176)
4360 * AUTOMAKE_OPTIONS <1>: Options. (line 17)
4361 * AUTOMAKE_OPTIONS <2>: Dependencies. (line 34)
4362 * AUTOMAKE_OPTIONS <3>: ANSI. (line 21)
4363 * AUTOMAKE_OPTIONS: Public Macros. (line 19)
4364 * bin_PROGRAMS: Program Sources. (line 6)
4365 * bin_SCRIPTS: Scripts. (line 18)
4366 * build_triplet: Optional. (line 14)
4367 * BUILT_SOURCES: Sources. (line 27)
4368 * CC: Program Variables. (line 12)
4369 * CCAS <1>: Assembly Support. (line 10)
4370 * CCAS: Public Macros. (line 75)
4371 * CCASFLAGS <1>: Assembly Support. (line 10)
4372 * CCASFLAGS: Public Macros. (line 75)
4373 * CFLAGS: Program Variables. (line 12)
4374 * check_: Uniform. (line 74)
4375 * check_LTLIBRARIES: Libtool Convenience Libraries.
4377 * check_PROGRAMS <1>: Default _SOURCES. (line 28)
4378 * check_PROGRAMS: Program Sources. (line 6)
4379 * check_SCRIPTS: Scripts. (line 18)
4380 * CLASSPATH_ENV: Java. (line 45)
4381 * CLEANFILES: Clean. (line 13)
4382 * COMPILE: Program Variables. (line 45)
4383 * CONFIG_STATUS_DEPENDENCIES: Rebuilding. (line 19)
4384 * CONFIGURE_DEPENDENCIES: Rebuilding. (line 19)
4385 * CPPFLAGS <1>: Assembly Support. (line 10)
4386 * CPPFLAGS: Program Variables. (line 12)
4387 * CXX: C++ Support. (line 16)
4388 * CXXCOMPILE: C++ Support. (line 25)
4389 * CXXFLAGS: C++ Support. (line 19)
4390 * CXXLINK <1>: How the Linker is Chosen.
4392 * CXXLINK: C++ Support. (line 29)
4393 * DATA <1>: Data. (line 7)
4394 * DATA: Uniform. (line 79)
4395 * data_DATA: Data. (line 9)
4396 * DEFS: Program Variables. (line 12)
4397 * DEJATOOL: DejaGnu Tests. (line 19)
4398 * DESTDIR <1>: Staged Installs. (line 6)
4399 * DESTDIR: DESTDIR. (line 6)
4400 * DISABLE_HARD_ERRORS: Simple Tests using parallel-tests.
4402 * dist_ <1>: Fine-grained Distribution Control.
4404 * dist_: Alternative. (line 29)
4405 * dist_lisp_LISP: Emacs Lisp. (line 11)
4406 * dist_noinst_LISP: Emacs Lisp. (line 11)
4407 * DIST_SUBDIRS <1>: Basics of Distribution.
4409 * DIST_SUBDIRS: Subdirectories with AM_CONDITIONAL.
4411 * DISTCHECK_CONFIGURE_FLAGS: Checking the Distribution.
4413 * distcleancheck_listfiles <1>: distcleancheck. (line 115)
4414 * distcleancheck_listfiles: Checking the Distribution.
4416 * DISTCLEANFILES <1>: Checking the Distribution.
4418 * DISTCLEANFILES: Clean. (line 13)
4419 * distdir <1>: Third-Party Makefiles.
4421 * distdir: The dist Hook. (line 24)
4422 * distuninstallcheck_listfiles: Checking the Distribution.
4424 * DVIPS: Texinfo. (line 130)
4425 * EMACS: Public Macros. (line 60)
4426 * ETAGS_ARGS: Tags. (line 25)
4427 * ETAGSFLAGS: Tags. (line 25)
4428 * EXPECT: DejaGnu Tests. (line 19)
4429 * EXT_LOG_COMPILE: Simple Tests using parallel-tests.
4431 * EXT_LOG_COMPILER: Simple Tests using parallel-tests.
4433 * EXT_LOG_FLAGS: Simple Tests using parallel-tests.
4435 * EXTRA_DIST: Basics of Distribution.
4437 * EXTRA_maude_SOURCES: Program and Library Variables.
4439 * EXTRA_PROGRAMS: Conditional Programs.
4441 * F77: Fortran 77 Support. (line 16)
4442 * F77COMPILE: Fortran 77 Support. (line 31)
4443 * F77LINK: How the Linker is Chosen.
4445 * FC: Fortran 9x Support. (line 16)
4446 * FCCOMPILE: Fortran 9x Support. (line 25)
4447 * FCFLAGS: Fortran 9x Support. (line 19)
4448 * FCLINK <1>: Fortran 9x Support. (line 29)
4449 * FCLINK: How the Linker is Chosen.
4451 * FFLAGS: Fortran 77 Support. (line 19)
4452 * FLIBS: Mixing Fortran 77 With C and C++.
4454 * FLINK: Fortran 77 Support. (line 35)
4455 * GCJ: Public Macros. (line 91)
4456 * GCJFLAGS <1>: Java Support. (line 14)
4457 * GCJFLAGS: Public Macros. (line 91)
4458 * GCJLINK: How the Linker is Chosen.
4460 * GTAGS_ARGS: Tags. (line 49)
4461 * GZIP_ENV: Basics of Distribution.
4463 * HEADERS: Uniform. (line 79)
4464 * host_triplet: Optional. (line 14)
4465 * include_HEADERS: Headers. (line 6)
4466 * INCLUDES: Program Variables. (line 33)
4467 * info_TEXINFOS: Texinfo. (line 6)
4468 * JAVA: Uniform. (line 79)
4469 * JAVAC: Java. (line 29)
4470 * JAVACFLAGS: Java. (line 32)
4471 * JAVAROOT: Java. (line 41)
4472 * LDADD: Linking. (line 10)
4473 * LDFLAGS: Program Variables. (line 12)
4474 * LFLAGS: Yacc and Lex. (line 56)
4475 * lib_LIBRARIES: A Library. (line 6)
4476 * lib_LTLIBRARIES: Libtool Libraries. (line 6)
4477 * libexec_PROGRAMS: Program Sources. (line 6)
4478 * libexec_SCRIPTS: Scripts. (line 18)
4479 * LIBOBJS <1>: LIBOBJS. (line 6)
4480 * LIBOBJS <2>: LTLIBOBJS. (line 6)
4481 * LIBOBJS: Optional. (line 68)
4482 * LIBRARIES: Uniform. (line 79)
4483 * LIBS: Program Variables. (line 12)
4484 * LIBTOOLFLAGS: Libtool Flags. (line 6)
4485 * LINK <1>: How the Linker is Chosen.
4487 * LINK: Program Variables. (line 54)
4488 * LISP: Uniform. (line 79)
4489 * lisp_LISP: Emacs Lisp. (line 6)
4490 * lispdir: Public Macros. (line 60)
4491 * localstate_DATA: Data. (line 9)
4492 * LOG_COMPILE: Simple Tests using parallel-tests.
4494 * LOG_COMPILER: Simple Tests using parallel-tests.
4496 * LOG_FLAGS: Simple Tests using parallel-tests.
4498 * LTALLOCA <1>: LIBOBJS. (line 6)
4499 * LTALLOCA: LTLIBOBJS. (line 6)
4500 * LTLIBOBJS <1>: LIBOBJS. (line 6)
4501 * LTLIBOBJS: LTLIBOBJS. (line 6)
4502 * MAINTAINERCLEANFILES: Clean. (line 13)
4503 * MAKE: Subdirectories. (line 29)
4504 * MAKEINFO: Texinfo. (line 88)
4505 * MAKEINFOFLAGS: Texinfo. (line 98)
4506 * MAKEINFOHTML: Texinfo. (line 94)
4507 * man_MANS: Man Pages. (line 6)
4508 * MANS: Uniform. (line 79)
4509 * maude_AR: Program and Library Variables.
4511 * maude_CCASFLAGS: Program and Library Variables.
4513 * maude_CFLAGS: Program and Library Variables.
4515 * maude_CPPFLAGS: Program and Library Variables.
4517 * maude_CXXFLAGS: Program and Library Variables.
4519 * maude_DEPENDENCIES <1>: Program and Library Variables.
4521 * maude_DEPENDENCIES: Linking. (line 41)
4522 * maude_FFLAGS: Program and Library Variables.
4524 * maude_GCJFLAGS: Program and Library Variables.
4526 * maude_LDADD <1>: Program and Library Variables.
4528 * maude_LDADD: Linking. (line 17)
4529 * maude_LDFLAGS <1>: Program and Library Variables.
4531 * maude_LDFLAGS: Linking. (line 37)
4532 * maude_LFLAGS: Program and Library Variables.
4534 * maude_LIBADD <1>: Program and Library Variables.
4536 * maude_LIBADD: A Library. (line 26)
4537 * maude_LIBTOOLFLAGS <1>: Program and Library Variables.
4539 * maude_LIBTOOLFLAGS: Libtool Flags. (line 6)
4540 * maude_LINK: Program and Library Variables.
4542 * maude_OBJCFLAGS: Program and Library Variables.
4544 * maude_RFLAGS: Program and Library Variables.
4546 * maude_SHORTNAME: Program and Library Variables.
4548 * maude_SOURCES: Program and Library Variables.
4550 * maude_UPCFLAGS: Program and Library Variables.
4552 * maude_YFLAGS: Program and Library Variables.
4554 * mkdir_p: Obsolete Macros. (line 31)
4555 * MKDIR_P: Obsolete Macros. (line 31)
4556 * MOSTLYCLEANFILES: Clean. (line 13)
4557 * nobase_: Alternative. (line 23)
4558 * nodist_ <1>: Fine-grained Distribution Control.
4560 * nodist_: Alternative. (line 29)
4561 * noinst_: Uniform. (line 69)
4562 * noinst_HEADERS: Headers. (line 6)
4563 * noinst_LIBRARIES: A Library. (line 6)
4564 * noinst_LISP: Emacs Lisp. (line 6)
4565 * noinst_LTLIBRARIES: Libtool Convenience Libraries.
4567 * noinst_PROGRAMS: Program Sources. (line 6)
4568 * noinst_SCRIPTS: Scripts. (line 18)
4569 * notrans_: Man Pages. (line 54)
4570 * OBJC: Objective C Support. (line 16)
4571 * OBJCCOMPILE: Objective C Support. (line 25)
4572 * OBJCFLAGS: Objective C Support. (line 19)
4573 * OBJCLINK <1>: How the Linker is Chosen.
4575 * OBJCLINK: Objective C Support. (line 29)
4576 * oldinclude_HEADERS: Headers. (line 6)
4577 * PACKAGE: Basics of Distribution.
4579 * pkgdata_DATA: Data. (line 9)
4580 * pkgdata_SCRIPTS: Scripts. (line 18)
4581 * pkgdatadir: Uniform. (line 19)
4582 * pkginclude_HEADERS: Headers. (line 6)
4583 * pkgincludedir: Uniform. (line 19)
4584 * pkglib_LIBRARIES: A Library. (line 6)
4585 * pkglib_LTLIBRARIES: Libtool Libraries. (line 6)
4586 * pkglib_PROGRAMS: Program Sources. (line 6)
4587 * pkglibdir: Uniform. (line 19)
4588 * pkglibexecdir: Uniform. (line 19)
4589 * pkgpyexecdir: Python. (line 101)
4590 * pkgpythondir: Python. (line 87)
4591 * PROGRAMS: Uniform. (line 17)
4592 * pyexecdir: Python. (line 92)
4593 * PYTHON <1>: Python. (line 52)
4594 * PYTHON: Uniform. (line 79)
4595 * PYTHON_EXEC_PREFIX: Python. (line 73)
4596 * PYTHON_PLATFORM: Python. (line 78)
4597 * PYTHON_PREFIX: Python. (line 68)
4598 * PYTHON_VERSION: Python. (line 64)
4599 * pythondir: Python. (line 83)
4600 * RECHECK_LOGS: Simple Tests using parallel-tests.
4602 * RFLAGS: Fortran 77 Support. (line 25)
4603 * RST2HTML: Simple Tests using parallel-tests.
4605 * RUNTEST: DejaGnu Tests. (line 19)
4606 * RUNTESTDEFAULTFLAGS: DejaGnu Tests. (line 14)
4607 * RUNTESTFLAGS: DejaGnu Tests. (line 24)
4608 * sbin_PROGRAMS: Program Sources. (line 6)
4609 * sbin_SCRIPTS: Scripts. (line 18)
4610 * SCRIPTS <1>: Scripts. (line 9)
4611 * SCRIPTS: Uniform. (line 79)
4612 * sharedstate_DATA: Data. (line 9)
4613 * SOURCES <1>: Default _SOURCES. (line 6)
4614 * SOURCES: Program Sources. (line 33)
4615 * SUBDIRS <1>: Basics of Distribution.
4617 * SUBDIRS: Subdirectories. (line 8)
4618 * SUFFIXES: Suffixes. (line 6)
4619 * sysconf_DATA: Data. (line 9)
4620 * TAGS_DEPENDENCIES: Tags. (line 35)
4621 * target_triplet: Optional. (line 14)
4622 * TEST_EXTENSIONS: Simple Tests using parallel-tests.
4624 * TEST_LOGS: Simple Tests using parallel-tests.
4626 * TEST_SUITE_HTML: Simple Tests using parallel-tests.
4628 * TEST_SUITE_LOG: Simple Tests using parallel-tests.
4630 * TESTS <1>: Simple Tests using parallel-tests.
4632 * TESTS: Simple Tests. (line 32)
4633 * TESTS_ENVIRONMENT: Simple Tests. (line 32)
4634 * TEXI2DVI: Texinfo. (line 121)
4635 * TEXI2PDF: Texinfo. (line 126)
4636 * TEXINFO_TEX: Texinfo. (line 134)
4637 * TEXINFOS <1>: Texinfo. (line 59)
4638 * TEXINFOS: Uniform. (line 79)
4639 * top_distdir <1>: Third-Party Makefiles.
4641 * top_distdir: The dist Hook. (line 24)
4642 * U: Obsolete Macros. (line 13)
4643 * UPC <1>: Unified Parallel C Support.
4645 * UPC: Public Macros. (line 96)
4646 * UPCCOMPILE: Unified Parallel C Support.
4648 * UPCFLAGS: Unified Parallel C Support.
4650 * UPCLINK <1>: How the Linker is Chosen.
4652 * UPCLINK: Unified Parallel C Support.
4654 * V: Options. (line 163)
4655 * VALAC: Vala Support. (line 29)
4656 * VALAFLAGS: Vala Support. (line 32)
4657 * VERBOSE: Simple Tests using parallel-tests.
4659 * VERSION: Basics of Distribution.
4661 * WARNINGS <1>: aclocal Options. (line 85)
4662 * WARNINGS: Invoking Automake. (line 168)
4663 * WITH_DMALLOC: Public Macros. (line 106)
4664 * WITH_REGEX: Public Macros. (line 111)
4665 * XFAIL_TESTS: Simple Tests. (line 44)
4666 * YACC: Optional. (line 119)
4667 * YFLAGS: Yacc and Lex. (line 33)
4670 File: automake.info, Node: General Index, Prev: Variable Index, Up: Indices
4678 * ## (special Automake comment): General Operation. (line 58)
4679 * #serial syntax: Serials. (line 6)
4680 * $(LIBOBJS) and empty libraries: LIBOBJS. (line 71)
4681 * +=: General Operation. (line 23)
4682 * --acdir: aclocal Options. (line 9)
4683 * --add-missing: Invoking Automake. (line 41)
4684 * --build=BUILD: Cross-Compilation. (line 14)
4685 * --copy: Invoking Automake. (line 66)
4686 * --cygnus: Invoking Automake. (line 70)
4687 * --diff: aclocal Options. (line 13)
4688 * --disable-dependency-tracking: Dependency Tracking. (line 29)
4689 * --disable-maintainer-mode: Optional. (line 175)
4690 * --disable-silent-rules: Options. (line 158)
4691 * --dry-run: aclocal Options. (line 18)
4692 * --enable-debug, example: Usage of Conditionals.
4694 * --enable-dependency-tracking: Dependency Tracking. (line 39)
4695 * --enable-maintainer-mode: Optional. (line 175)
4696 * --enable-silent-rules: Options. (line 158)
4697 * --force: aclocal Options. (line 39)
4698 * --force-missing: Invoking Automake. (line 75)
4699 * --foreign: Invoking Automake. (line 81)
4700 * --gnits: Invoking Automake. (line 85)
4701 * --gnits, complete description: Gnits. (line 29)
4702 * --gnu: Invoking Automake. (line 89)
4703 * --gnu, complete description: Gnits. (line 6)
4704 * --gnu, required files: Gnits. (line 6)
4705 * --help <1>: aclocal Options. (line 22)
4706 * --help: Invoking Automake. (line 93)
4707 * --help check: Options. (line 200)
4708 * --help=recursive: Nested Packages. (line 30)
4709 * --host=HOST: Cross-Compilation. (line 17)
4710 * --include-deps: Invoking Automake. (line 101)
4711 * --install: aclocal Options. (line 29)
4712 * --libdir: Invoking Automake. (line 61)
4713 * --no-force: Invoking Automake. (line 106)
4714 * --output: aclocal Options. (line 49)
4715 * --output-dir: Invoking Automake. (line 113)
4716 * --prefix: Standard Directory Variables.
4718 * --print-ac-dir: aclocal Options. (line 52)
4719 * --program-prefix=PREFIX: Renaming. (line 16)
4720 * --program-suffix=SUFFIX: Renaming. (line 19)
4721 * --program-transform-name=PROGRAM: Renaming. (line 22)
4722 * --target=TARGET: Cross-Compilation. (line 56)
4723 * --verbose <1>: aclocal Options. (line 58)
4724 * --verbose: Invoking Automake. (line 120)
4725 * --version <1>: aclocal Options. (line 61)
4726 * --version: Invoking Automake. (line 124)
4727 * --version check: Options. (line 200)
4728 * --warnings <1>: aclocal Options. (line 66)
4729 * --warnings: Invoking Automake. (line 128)
4730 * --with-dmalloc: Public Macros. (line 106)
4731 * --with-regex: Public Macros. (line 111)
4732 * -a: Invoking Automake. (line 41)
4733 * -c: Invoking Automake. (line 65)
4734 * -f: Invoking Automake. (line 74)
4735 * -hook targets: Extending. (line 68)
4736 * -I: aclocal Options. (line 25)
4737 * -i: Invoking Automake. (line 97)
4738 * -l and LDADD: Linking. (line 66)
4739 * -local targets: Extending. (line 39)
4740 * -module, libtool: Libtool Modules. (line 6)
4741 * -o: Invoking Automake. (line 113)
4742 * -v: Invoking Automake. (line 120)
4743 * -W <1>: aclocal Options. (line 66)
4744 * -W: Invoking Automake. (line 128)
4745 * -Wall: amhello Explained. (line 38)
4746 * -Werror: amhello Explained. (line 38)
4747 * .la suffix, defined: Libtool Concept. (line 6)
4748 * _DATA primary, defined: Data. (line 6)
4749 * _DEPENDENCIES, defined: Linking. (line 41)
4750 * _HEADERS primary, defined: Headers. (line 6)
4751 * _JAVA primary, defined: Java. (line 6)
4752 * _LDFLAGS, defined: Linking. (line 37)
4753 * _LDFLAGS, libtool: Libtool Flags. (line 6)
4754 * _LIBADD, libtool: Libtool Flags. (line 6)
4755 * _LIBRARIES primary, defined: A Library. (line 6)
4756 * _LIBTOOLFLAGS, libtool: Libtool Flags. (line 6)
4757 * _LISP primary, defined: Emacs Lisp. (line 6)
4758 * _LTLIBRARIES primary, defined: Libtool Libraries. (line 6)
4759 * _MANS primary, defined: Man Pages. (line 6)
4760 * _PROGRAMS primary variable: Uniform. (line 11)
4761 * _PYTHON primary, defined: Python. (line 6)
4762 * _SCRIPTS primary, defined: Scripts. (line 6)
4763 * _SOURCES and header files: Program Sources. (line 39)
4764 * _SOURCES primary, defined: Program Sources. (line 32)
4765 * _SOURCES, default: Default _SOURCES. (line 6)
4766 * _SOURCES, empty: Default _SOURCES. (line 44)
4767 * _TEXINFOS primary, defined: Texinfo. (line 6)
4768 * AC_CONFIG_FILES, conditional: Usage of Conditionals.
4770 * AC_SUBST and SUBDIRS: Subdirectories with AC_SUBST.
4772 * acinclude.m4, defined: Complete. (line 23)
4773 * aclocal and serial numbers: Serials. (line 6)
4774 * aclocal program, introduction: Complete. (line 23)
4775 * aclocal search path: Macro Search Path. (line 6)
4776 * aclocal's scheduled death: Future of aclocal. (line 6)
4777 * aclocal, extending: Extending aclocal. (line 6)
4778 * aclocal, Invoking: Invoking aclocal. (line 6)
4779 * aclocal, Options: aclocal Options. (line 6)
4780 * aclocal.m4, preexisting: Complete. (line 23)
4781 * Adding new SUFFIXES: Suffixes. (line 6)
4782 * all <1>: Extending. (line 43)
4783 * all: Standard Targets. (line 16)
4784 * all-local: Extending. (line 43)
4785 * ALLOCA, and Libtool: LTLIBOBJS. (line 6)
4786 * ALLOCA, example: LIBOBJS. (line 6)
4787 * ALLOCA, special handling: LIBOBJS. (line 6)
4788 * AM_CCASFLAGS and CCASFLAGS: Flag Variables Ordering.
4790 * AM_CFLAGS and CFLAGS: Flag Variables Ordering.
4792 * AM_CONDITIONAL and SUBDIRS: Subdirectories with AM_CONDITIONAL.
4794 * AM_CPPFLAGS and CPPFLAGS: Flag Variables Ordering.
4796 * AM_CXXFLAGS and CXXFLAGS: Flag Variables Ordering.
4798 * AM_FCFLAGS and FCFLAGS: Flag Variables Ordering.
4800 * AM_FFLAGS and FFLAGS: Flag Variables Ordering.
4802 * AM_GCJFLAGS and GCJFLAGS: Flag Variables Ordering.
4804 * AM_INIT_AUTOMAKE, example use: Complete. (line 11)
4805 * AM_LDFLAGS and LDFLAGS: Flag Variables Ordering.
4807 * AM_LFLAGS and LFLAGS: Flag Variables Ordering.
4809 * AM_LIBTOOLFLAGS and LIBTOOLFLAGS: Flag Variables Ordering.
4811 * AM_MAINTAINER_MODE, purpose: maintainer-mode. (line 36)
4812 * AM_OBJCFLAGS and OBJCFLAGS: Flag Variables Ordering.
4814 * AM_RFLAGS and RFLAGS: Flag Variables Ordering.
4816 * AM_UPCFLAGS and UPCFLAGS: Flag Variables Ordering.
4818 * AM_YFLAGS and YFLAGS: Flag Variables Ordering.
4820 * amhello-1.0.tar.gz, creation: Hello World. (line 6)
4821 * amhello-1.0.tar.gz, location: Use Cases. (line 6)
4822 * amhello-1.0.tar.gz, use cases: Use Cases. (line 6)
4823 * ansi2knr <1>: Options. (line 28)
4824 * ansi2knr: ANSI. (line 21)
4825 * ansi2knr and LIBOBJS: ANSI. (line 57)
4826 * ansi2knr and LTLIBOBJS: ANSI. (line 57)
4827 * Append operator: General Operation. (line 23)
4828 * ARG_MAX: Length Limitations. (line 6)
4829 * autogen.sh and autoreconf: Error required file ltmain.sh not found.
4831 * autom4te: Invoking aclocal. (line 45)
4832 * Automake constraints: Introduction. (line 22)
4833 * automake options: Invoking Automake. (line 37)
4834 * Automake requirements <1>: Requirements. (line 6)
4835 * Automake requirements: Introduction. (line 27)
4836 * automake, invoking: Invoking Automake. (line 6)
4837 * Automake, recursive operation: General Operation. (line 48)
4838 * Automatic dependency tracking: Dependencies. (line 11)
4839 * Automatic linker selection: How the Linker is Chosen.
4841 * autoreconf and libtoolize: Error required file ltmain.sh not found.
4843 * autoreconf, example: Creating amhello. (line 59)
4844 * autoscan: amhello Explained. (line 90)
4845 * Autotools, introduction: GNU Build System. (line 43)
4846 * Autotools, purpose: Why Autotools. (line 6)
4847 * autoupdate: Obsolete Macros. (line 6)
4848 * Auxiliary programs: Auxiliary Programs. (line 6)
4849 * Avoiding man page renaming: Man Pages. (line 54)
4850 * Avoiding path stripping: Alternative. (line 23)
4851 * Binary package: DESTDIR. (line 22)
4852 * bootstrap.sh and autoreconf: Error required file ltmain.sh not found.
4854 * Bugs, reporting: Introduction. (line 31)
4855 * build tree and source tree: VPATH Builds. (line 6)
4856 * BUILT_SOURCES, defined: Sources. (line 27)
4857 * C++ support: C++ Support. (line 6)
4858 * canonicalizing Automake variables: Canonicalization. (line 6)
4859 * CCASFLAGS and AM_CCASFLAGS: Flag Variables Ordering.
4861 * CFLAGS and AM_CFLAGS: Flag Variables Ordering.
4863 * cfortran: Mixing Fortran 77 With C and C++.
4865 * check <1>: Extending. (line 43)
4866 * check <2>: Tests. (line 6)
4867 * check: Standard Targets. (line 37)
4868 * check-html: Simple Tests using parallel-tests.
4870 * check-local: Extending. (line 43)
4871 * check-news: Options. (line 35)
4872 * check_ primary prefix, definition: Uniform. (line 74)
4873 * check_PROGRAMS example: Default _SOURCES. (line 28)
4874 * clean <1>: Extending. (line 43)
4875 * clean: Standard Targets. (line 31)
4876 * clean-local <1>: Extending. (line 43)
4877 * clean-local: Clean. (line 15)
4878 * color-tests: Options. (line 39)
4879 * command line length limit: Length Limitations. (line 6)
4880 * Comment, special to Automake: General Operation. (line 58)
4881 * Compile Flag Variables: Flag Variables Ordering.
4883 * Complete example: Complete. (line 6)
4884 * Conditional example, --enable-debug: Usage of Conditionals.
4886 * conditional libtool libraries: Conditional Libtool Libraries.
4888 * Conditional programs: Conditional Programs.
4890 * Conditional subdirectories: Conditional Subdirectories.
4892 * Conditional SUBDIRS: Conditional Subdirectories.
4894 * Conditionals: Conditionals. (line 6)
4895 * config.guess: Invoking Automake. (line 39)
4896 * config.site example: config.site. (line 6)
4897 * configuration variables, overriding: Standard Configuration Variables.
4899 * Configuration, basics: Basic Installation. (line 6)
4900 * configure.ac, scanning: configure. (line 6)
4901 * conflicting definitions: Extending. (line 14)
4902 * Constraints of Automake: Introduction. (line 22)
4903 * convenience libraries, libtool: Libtool Convenience Libraries.
4905 * copying semantics: Extending. (line 10)
4906 * cpio example: Uniform. (line 36)
4907 * CPPFLAGS and AM_CPPFLAGS: Flag Variables Ordering.
4909 * cross-compilation: Cross-Compilation. (line 6)
4910 * cross-compilation example: Cross-Compilation. (line 26)
4911 * CVS and generated files: CVS. (line 49)
4912 * CVS and third-party files: CVS. (line 140)
4913 * CVS and timestamps: CVS. (line 28)
4914 * cvs-dist: General Operation. (line 12)
4915 * cvs-dist, non-standard example: General Operation. (line 12)
4916 * CXXFLAGS and AM_CXXFLAGS: Flag Variables Ordering.
4918 * cygnus: Options. (line 23)
4919 * cygnus strictness: Cygnus. (line 6)
4920 * DATA primary, defined: Data. (line 6)
4921 * de-ANSI-fication, defined: ANSI. (line 6)
4922 * debug build, example: VPATH Builds. (line 47)
4923 * debugging rules: Debugging Make Rules.
4925 * default _SOURCES: Default _SOURCES. (line 6)
4926 * default source, Libtool modules example: Default _SOURCES. (line 38)
4927 * default verbosity for silent-rules: Options. (line 154)
4928 * definitions, conflicts: Extending. (line 14)
4929 * dejagnu <1>: Options. (line 43)
4930 * dejagnu: DejaGnu Tests. (line 19)
4931 * depcomp: Dependencies. (line 22)
4932 * dependencies and distributed files: distcleancheck. (line 6)
4933 * Dependency tracking <1>: Dependencies. (line 11)
4934 * Dependency tracking: Dependency Tracking. (line 6)
4935 * Dependency tracking, disabling: Dependencies. (line 37)
4936 * directory variables: Standard Directory Variables.
4938 * dirlist: Macro Search Path. (line 62)
4939 * Disabling dependency tracking: Dependencies. (line 37)
4940 * dist <1>: Basics of Distribution.
4942 * dist: Standard Targets. (line 43)
4943 * dist-bzip2 <1>: Options. (line 47)
4944 * dist-bzip2: The Types of Distributions.
4946 * dist-gzip: The Types of Distributions.
4948 * dist-hook <1>: Extending. (line 68)
4949 * dist-hook: The dist Hook. (line 6)
4950 * dist-lzma <1>: Options. (line 50)
4951 * dist-lzma: The Types of Distributions.
4953 * dist-shar <1>: Options. (line 53)
4954 * dist-shar: The Types of Distributions.
4956 * dist-tarZ <1>: Options. (line 59)
4957 * dist-tarZ: The Types of Distributions.
4959 * dist-xz: The Types of Distributions.
4961 * dist-zip <1>: Options. (line 56)
4962 * dist-zip: The Types of Distributions.
4964 * dist_ and nobase_: Alternative. (line 29)
4965 * dist_ and notrans_: Man Pages. (line 63)
4966 * DIST_SUBDIRS, explained: SUBDIRS vs DIST_SUBDIRS.
4968 * distcheck <1>: Checking the Distribution.
4970 * distcheck: Creating amhello. (line 99)
4971 * distcheck better than dist: Preparing Distributions.
4973 * distcheck example: Creating amhello. (line 99)
4974 * distcheck-hook: Checking the Distribution.
4976 * distclean <1>: distcleancheck. (line 6)
4977 * distclean <2>: Extending. (line 43)
4978 * distclean: Standard Targets. (line 34)
4979 * distclean, diagnostic: distcleancheck. (line 6)
4980 * distclean-local <1>: Extending. (line 43)
4981 * distclean-local: Clean. (line 15)
4982 * distcleancheck <1>: distcleancheck. (line 6)
4983 * distcleancheck: Checking the Distribution.
4985 * distdir: Third-Party Makefiles.
4987 * Distributions, preparation: Preparing Distributions.
4989 * dmalloc, support for: Public Macros. (line 106)
4990 * dvi <1>: Extending. (line 43)
4991 * dvi: Texinfo. (line 19)
4992 * DVI output using Texinfo: Texinfo. (line 6)
4993 * dvi-local: Extending. (line 43)
4994 * E-mail, bug reports: Introduction. (line 31)
4995 * EDITION Texinfo flag: Texinfo. (line 29)
4996 * else: Usage of Conditionals.
4998 * empty _SOURCES: Default _SOURCES. (line 44)
4999 * Empty libraries: A Library. (line 46)
5000 * Empty libraries and $(LIBOBJS): LIBOBJS. (line 71)
5001 * endif: Usage of Conditionals.
5003 * Example conditional --enable-debug: Usage of Conditionals.
5005 * Example conditional AC_CONFIG_FILES: Usage of Conditionals.
5007 * Example Hello World: Hello World. (line 6)
5008 * Example of recursive operation: General Operation. (line 48)
5009 * Example of shared libraries: Libtool Libraries. (line 6)
5010 * Example, EXTRA_PROGRAMS: Uniform. (line 36)
5011 * Example, false and true: true. (line 6)
5012 * Example, mixed language: Mixing Fortran 77 With C and C++.
5014 * Executable extension: EXEEXT. (line 6)
5015 * Exit status 77, special interpretation: Simple Tests. (line 20)
5016 * Exit status 99, special interpretation: Simple Tests using parallel-tests.
5018 * Expected test failure: Simple Tests. (line 42)
5019 * Extending aclocal: Extending aclocal. (line 6)
5020 * Extending list of installation directories: Uniform. (line 55)
5021 * Extension, executable: EXEEXT. (line 6)
5022 * Extra files distributed with Automake: Invoking Automake. (line 39)
5023 * EXTRA_, prepending: Uniform. (line 29)
5024 * EXTRA_prog_SOURCES, defined: Conditional Sources. (line 18)
5025 * EXTRA_PROGRAMS, defined <1>: Conditional Programs.
5027 * EXTRA_PROGRAMS, defined: Uniform. (line 36)
5028 * false Example: true. (line 6)
5029 * FCFLAGS and AM_FCFLAGS: Flag Variables Ordering.
5031 * Features of the GNU Build System: Use Cases. (line 6)
5032 * FFLAGS and AM_FFLAGS: Flag Variables Ordering.
5034 * file names, limitations on: Limitations on File Names.
5036 * filename-length-max=99: Options. (line 62)
5037 * Files distributed with Automake: Invoking Automake. (line 39)
5038 * First line of Makefile.am: General Operation. (line 64)
5039 * Flag Variables, Ordering: Flag Variables Ordering.
5041 * Flag variables, ordering: Flag Variables Ordering.
5043 * FLIBS, defined: Mixing Fortran 77 With C and C++.
5045 * foreign <1>: Options. (line 23)
5046 * foreign: amhello Explained. (line 38)
5047 * foreign strictness: Strictness. (line 10)
5048 * Fortran 77 support: Fortran 77 Support. (line 6)
5049 * Fortran 77, mixing with C and C++: Mixing Fortran 77 With C and C++.
5051 * Fortran 77, Preprocessing: Preprocessing Fortran 77.
5053 * Fortran 9x support: Fortran 9x Support. (line 6)
5054 * GCJFLAGS and AM_GCJFLAGS: Flag Variables Ordering.
5056 * generated files and CVS: CVS. (line 49)
5057 * generated files, distributed: CVS. (line 9)
5058 * Gettext support: gettext. (line 6)
5059 * git-dist: General Operation. (line 12)
5060 * gnits: Options. (line 23)
5061 * gnits strictness: Strictness. (line 10)
5062 * gnu: Options. (line 23)
5063 * GNU Build System, basics: Basic Installation. (line 6)
5064 * GNU Build System, features: Use Cases. (line 6)
5065 * GNU Build System, introduction: GNU Build System. (line 6)
5066 * GNU Build System, use cases: Use Cases. (line 6)
5067 * GNU Coding Standards: GNU Build System. (line 29)
5068 * GNU Gettext support: gettext. (line 6)
5069 * GNU make extensions: General Operation. (line 19)
5070 * GNU Makefile standards: Introduction. (line 12)
5071 * gnu strictness: Strictness. (line 10)
5072 * GNUmakefile including Makefile: Third-Party Makefiles.
5074 * hard error: Simple Tests using parallel-tests.
5076 * Header files in _SOURCES: Program Sources. (line 39)
5077 * HEADERS primary, defined: Headers. (line 6)
5078 * HEADERS, installation directories: Headers. (line 6)
5079 * Hello World example: Hello World. (line 6)
5080 * hook targets: Extending. (line 68)
5081 * HP-UX 10, lex problems: Public Macros. (line 86)
5082 * html <1>: Extending. (line 43)
5083 * html: Texinfo. (line 19)
5084 * HTML output using Texinfo: Texinfo. (line 6)
5085 * html-local: Extending. (line 43)
5086 * id: Tags. (line 44)
5087 * if: Usage of Conditionals.
5089 * include <1>: Include. (line 6)
5090 * include: Basics of Distribution.
5092 * include, distribution: Basics of Distribution.
5094 * Including Makefile fragment: Include. (line 6)
5095 * indentation: General Operation. (line 29)
5096 * info <1>: Extending. (line 43)
5097 * info: Options. (line 103)
5098 * info-local: Extending. (line 43)
5099 * install <1>: Extending. (line 43)
5100 * install <2>: The Two Parts of Install.
5102 * install: Standard Targets. (line 19)
5103 * Install hook: Extending Installation.
5105 * Install, two parts of: The Two Parts of Install.
5107 * install-data <1>: Extending. (line 43)
5108 * install-data <2>: The Two Parts of Install.
5110 * install-data: Two-Part Install. (line 16)
5111 * install-data-hook: Extending. (line 68)
5112 * install-data-local <1>: Extending. (line 43)
5113 * install-data-local: Extending Installation.
5115 * install-dvi <1>: Extending. (line 43)
5116 * install-dvi: Texinfo. (line 19)
5117 * install-dvi-local: Extending. (line 43)
5118 * install-exec <1>: Extending. (line 43)
5119 * install-exec <2>: The Two Parts of Install.
5121 * install-exec: Two-Part Install. (line 16)
5122 * install-exec-hook: Extending. (line 68)
5123 * install-exec-local <1>: Extending. (line 43)
5124 * install-exec-local: Extending Installation.
5126 * install-html <1>: Extending. (line 43)
5127 * install-html: Texinfo. (line 19)
5128 * install-html-local: Extending. (line 43)
5129 * install-info <1>: Extending. (line 43)
5130 * install-info <2>: Options. (line 103)
5131 * install-info: Texinfo. (line 79)
5132 * install-info target: Texinfo. (line 79)
5133 * install-info-local: Extending. (line 43)
5134 * install-man <1>: Options. (line 109)
5135 * install-man: Man Pages. (line 32)
5136 * install-man target: Man Pages. (line 32)
5137 * install-pdf <1>: Extending. (line 43)
5138 * install-pdf: Texinfo. (line 19)
5139 * install-pdf-local: Extending. (line 43)
5140 * install-ps <1>: Extending. (line 43)
5141 * install-ps: Texinfo. (line 19)
5142 * install-ps-local: Extending. (line 43)
5143 * install-strip <1>: Install Rules for the User.
5145 * install-strip: Standard Targets. (line 23)
5146 * Installation directories, extending list: Uniform. (line 55)
5147 * Installation support: Install. (line 6)
5148 * Installation, basics: Basic Installation. (line 6)
5149 * installcheck <1>: Extending. (line 43)
5150 * installcheck: Standard Targets. (line 40)
5151 * installcheck-local: Extending. (line 43)
5152 * installdirs <1>: Extending. (line 43)
5153 * installdirs: Install Rules for the User.
5155 * installdirs-local: Extending. (line 43)
5156 * Installing headers: Headers. (line 6)
5157 * Installing scripts: Scripts. (line 6)
5158 * installing versioned binaries: Extending. (line 88)
5159 * Interfacing with third-party packages: Third-Party Makefiles.
5161 * Invoking aclocal: Invoking aclocal. (line 6)
5162 * Invoking automake: Invoking Automake. (line 6)
5163 * JAVA primary, defined: Java. (line 6)
5164 * JAVA restrictions: Java. (line 19)
5165 * Java support: Java Support. (line 6)
5166 * lazy test execution: Simple Tests using parallel-tests.
5168 * LDADD and -l: Linking. (line 66)
5169 * LDFLAGS and AM_LDFLAGS: Flag Variables Ordering.
5171 * lex problems with HP-UX 10: Public Macros. (line 86)
5172 * lex, multiple lexers: Yacc and Lex. (line 64)
5173 * LFLAGS and AM_LFLAGS: Flag Variables Ordering.
5175 * libltdl, introduction: Libtool Concept. (line 30)
5176 * LIBOBJS and ansi2knr: ANSI. (line 57)
5177 * LIBOBJS, and Libtool: LTLIBOBJS. (line 6)
5178 * LIBOBJS, example: LIBOBJS. (line 6)
5179 * LIBOBJS, special handling: LIBOBJS. (line 6)
5180 * LIBRARIES primary, defined: A Library. (line 6)
5181 * libtool convenience libraries: Libtool Convenience Libraries.
5183 * libtool libraries, conditional: Conditional Libtool Libraries.
5185 * libtool library, definition: Libtool Concept. (line 6)
5186 * libtool modules: Libtool Modules. (line 6)
5187 * Libtool modules, default source example: Default _SOURCES. (line 38)
5188 * libtool, introduction: Libtool Concept. (line 6)
5189 * LIBTOOLFLAGS and AM_LIBTOOLFLAGS: Flag Variables Ordering.
5191 * libtoolize and autoreconf: Error required file ltmain.sh not found.
5193 * libtoolize, no longer run by automake: Error required file ltmain.sh not found.
5195 * Linking Fortran 77 with C and C++: Mixing Fortran 77 With C and C++.
5197 * LISP primary, defined: Emacs Lisp. (line 6)
5198 * LN_S example: Extending. (line 88)
5199 * local targets: Extending. (line 39)
5200 * LTALLOCA, special handling: LTLIBOBJS. (line 6)
5201 * LTLIBOBJS and ansi2knr: ANSI. (line 57)
5202 * LTLIBOBJS, special handling: LTLIBOBJS. (line 6)
5203 * LTLIBRARIES primary, defined: Libtool Libraries. (line 6)
5204 * ltmain.sh not found: Error required file ltmain.sh not found.
5206 * m4_include, distribution: Basics of Distribution.
5208 * Macro search path: Macro Search Path. (line 6)
5209 * macro serial numbers: Serials. (line 6)
5210 * Macros Automake recognizes: Optional. (line 6)
5211 * maintainer-clean-local: Clean. (line 15)
5212 * make check: Tests. (line 6)
5213 * make clean support: Clean. (line 6)
5214 * make dist: Basics of Distribution.
5216 * make distcheck: Checking the Distribution.
5218 * make distclean, diagnostic: distcleancheck. (line 6)
5219 * make distcleancheck: Checking the Distribution.
5221 * make distuninstallcheck: Checking the Distribution.
5223 * make install support: Install. (line 6)
5224 * make installcheck, testing --help and --version: Options. (line 200)
5225 * Make rules, overriding: General Operation. (line 36)
5226 * Make targets, overriding: General Operation. (line 36)
5227 * Makefile fragment, including: Include. (line 6)
5228 * Makefile.am, first line: General Operation. (line 64)
5229 * Makefile.am, Hello World: amhello Explained. (line 96)
5230 * Man page renaming, avoiding: Man Pages. (line 54)
5231 * MANS primary, defined: Man Pages. (line 6)
5232 * many outputs, rules with: Multiple Outputs. (line 6)
5233 * mdate-sh: Texinfo. (line 29)
5234 * MinGW cross-compilation example: Cross-Compilation. (line 26)
5235 * missing, purpose: maintainer-mode. (line 9)
5236 * Mixed language example: Mixing Fortran 77 With C and C++.
5238 * Mixing Fortran 77 with C and C++: Mixing Fortran 77 With C and C++.
5240 * Mixing Fortran 77 with C and/or C++: Mixing Fortran 77 With C and C++.
5242 * mkdir -p, macro check: Obsolete Macros. (line 31)
5243 * modules, libtool: Libtool Modules. (line 6)
5244 * mostlyclean <1>: Extending. (line 43)
5245 * mostlyclean: Simple Tests using parallel-tests.
5247 * mostlyclean-local <1>: Extending. (line 43)
5248 * mostlyclean-local: Clean. (line 15)
5249 * multiple configurations, example: VPATH Builds. (line 47)
5250 * Multiple configure.ac files: Invoking Automake. (line 6)
5251 * Multiple lex lexers: Yacc and Lex. (line 64)
5252 * multiple outputs, rules with: Multiple Outputs. (line 6)
5253 * Multiple yacc parsers: Yacc and Lex. (line 64)
5254 * Nested packages: Nested Packages. (line 6)
5255 * Nesting packages: Subpackages. (line 6)
5256 * no-define <1>: Options. (line 71)
5257 * no-define: Public Macros. (line 54)
5258 * no-dependencies <1>: Options. (line 76)
5259 * no-dependencies: Dependencies. (line 34)
5260 * no-dist: Options. (line 83)
5261 * no-dist-gzip: Options. (line 87)
5262 * no-exeext: Options. (line 90)
5263 * no-installinfo <1>: Options. (line 100)
5264 * no-installinfo: Texinfo. (line 79)
5265 * no-installinfo option: Texinfo. (line 79)
5266 * no-installman <1>: Options. (line 106)
5267 * no-installman: Man Pages. (line 32)
5268 * no-installman option: Man Pages. (line 32)
5269 * no-texinfo.tex: Options. (line 116)
5270 * nobase_ and dist_ or nodist_: Alternative. (line 29)
5271 * nobase_ prefix: Alternative. (line 23)
5272 * nodist_ and nobase_: Alternative. (line 29)
5273 * nodist_ and notrans_: Man Pages. (line 63)
5274 * noinst_ primary prefix, definition: Uniform. (line 69)
5275 * Non-GNU packages: Strictness. (line 6)
5276 * Non-standard targets: General Operation. (line 12)
5277 * nostdinc: Options. (line 112)
5278 * notrans_ and dist_ or nodist_: Man Pages. (line 63)
5279 * notrans_ prefix: Man Pages. (line 54)
5280 * OBJCFLAGS and AM_OBJCFLAGS: Flag Variables Ordering.
5282 * Objective C support: Objective C Support. (line 6)
5283 * Objects in subdirectory: Program and Library Variables.
5285 * obsolete macros: Obsolete Macros. (line 6)
5286 * optimized build, example: VPATH Builds. (line 47)
5287 * Option, --warnings=CATEGORY: Options. (line 282)
5288 * Option, -WCATEGORY: Options. (line 282)
5289 * Option, ansi2knr: Options. (line 28)
5290 * Option, check-news: Options. (line 35)
5291 * Option, color-tests: Options. (line 39)
5292 * Option, cygnus: Options. (line 23)
5293 * Option, dejagnu: Options. (line 43)
5294 * Option, dist-bzip2: Options. (line 47)
5295 * Option, dist-lzma: Options. (line 50)
5296 * Option, dist-shar: Options. (line 53)
5297 * Option, dist-tarZ: Options. (line 59)
5298 * Option, dist-zip: Options. (line 56)
5299 * Option, filename-length-max=99: Options. (line 62)
5300 * Option, foreign: Options. (line 23)
5301 * Option, gnits: Options. (line 23)
5302 * Option, gnu: Options. (line 23)
5303 * Option, no-define: Options. (line 71)
5304 * Option, no-dependencies: Options. (line 76)
5305 * Option, no-dist: Options. (line 83)
5306 * Option, no-dist-gzip: Options. (line 87)
5307 * Option, no-exeext: Options. (line 90)
5308 * Option, no-installinfo <1>: Options. (line 100)
5309 * Option, no-installinfo: Texinfo. (line 79)
5310 * Option, no-installman <1>: Options. (line 106)
5311 * Option, no-installman: Man Pages. (line 32)
5312 * Option, no-texinfo.tex: Options. (line 116)
5313 * Option, nostdinc: Options. (line 112)
5314 * Option, parallel-tests: Options. (line 120)
5315 * Option, readme-alpha: Options. (line 124)
5316 * Option, silent-rules: Options. (line 133)
5317 * Option, tar-pax: Options. (line 232)
5318 * Option, tar-ustar: Options. (line 232)
5319 * Option, tar-v7: Options. (line 232)
5320 * Option, VERSION: Options. (line 277)
5321 * Option, warnings: Options. (line 282)
5322 * Options, aclocal: aclocal Options. (line 6)
5323 * Options, automake: Invoking Automake. (line 37)
5324 * Options, std-options: Options. (line 200)
5325 * Options, subdir-objects: Options. (line 220)
5326 * Ordering flag variables: Flag Variables Ordering.
5328 * Overriding make rules: General Operation. (line 36)
5329 * Overriding make targets: General Operation. (line 36)
5330 * Overriding make variables: General Operation. (line 41)
5331 * overriding rules: Extending. (line 27)
5332 * overriding semantics: Extending. (line 27)
5333 * PACKAGE, directory: Uniform. (line 19)
5334 * PACKAGE, prevent definition: Public Macros. (line 54)
5335 * Packages, nested: Nested Packages. (line 6)
5336 * Packages, preparation: Preparing Distributions.
5338 * Parallel build trees: VPATH Builds. (line 6)
5339 * parallel-tests: Options. (line 120)
5340 * parallel-tests, Using: Simple Tests using parallel-tests.
5342 * Path stripping, avoiding: Alternative. (line 23)
5343 * pax format: Options. (line 232)
5344 * pdf <1>: Extending. (line 43)
5345 * pdf: Texinfo. (line 19)
5346 * PDF output using Texinfo: Texinfo. (line 6)
5347 * pdf-local: Extending. (line 43)
5348 * Per-object flags, emulated: Per-Object Flags. (line 6)
5349 * per-target compilation flags, defined: Program and Library Variables.
5351 * pkgdatadir, defined: Uniform. (line 19)
5352 * pkgincludedir, defined: Uniform. (line 19)
5353 * pkglibdir, defined: Uniform. (line 19)
5354 * pkglibexecdir, defined: Uniform. (line 19)
5355 * POSIX termios headers: Obsolete Macros. (line 53)
5356 * Preparing distributions: Preparing Distributions.
5358 * Preprocessing Fortran 77: Preprocessing Fortran 77.
5360 * Primary variable, DATA: Data. (line 6)
5361 * Primary variable, defined: Uniform. (line 11)
5362 * Primary variable, HEADERS: Headers. (line 6)
5363 * Primary variable, JAVA: Java. (line 6)
5364 * Primary variable, LIBRARIES: A Library. (line 6)
5365 * Primary variable, LISP: Emacs Lisp. (line 6)
5366 * Primary variable, LTLIBRARIES: Libtool Libraries. (line 6)
5367 * Primary variable, MANS: Man Pages. (line 6)
5368 * Primary variable, PROGRAMS: Uniform. (line 11)
5369 * Primary variable, PYTHON: Python. (line 6)
5370 * Primary variable, SCRIPTS: Scripts. (line 6)
5371 * Primary variable, SOURCES: Program Sources. (line 32)
5372 * Primary variable, TEXINFOS: Texinfo. (line 6)
5373 * prog_LDADD, defined: Linking. (line 12)
5374 * PROGRAMS primary variable: Uniform. (line 11)
5375 * Programs, auxiliary: Auxiliary Programs. (line 6)
5376 * PROGRAMS, bindir: Program Sources. (line 6)
5377 * Programs, conditional: Conditional Programs.
5379 * Programs, renaming during installation: Renaming. (line 6)
5380 * Proxy Makefile for third-party packages: Third-Party Makefiles.
5382 * ps <1>: Extending. (line 43)
5383 * ps: Texinfo. (line 19)
5384 * PS output using Texinfo: Texinfo. (line 6)
5385 * ps-local: Extending. (line 43)
5386 * PYTHON primary, defined: Python. (line 6)
5387 * Ratfor programs: Preprocessing Fortran 77.
5389 * read-only source tree: VPATH Builds. (line 90)
5390 * README-alpha: Gnits. (line 42)
5391 * readme-alpha: Options. (line 124)
5392 * rebuild rules <1>: CVS. (line 9)
5393 * rebuild rules: Rebuilding. (line 6)
5394 * recheck: Simple Tests using parallel-tests.
5396 * recheck-html: Simple Tests using parallel-tests.
5398 * Recognized macros by Automake: Optional. (line 6)
5399 * Recursive operation of Automake: General Operation. (line 48)
5400 * recursive targets and third-party Makefiles: Third-Party Makefiles.
5402 * regex package: Public Macros. (line 111)
5403 * Renaming programs: Renaming. (line 6)
5404 * Reporting bugs: Introduction. (line 31)
5405 * Requirements of Automake: Requirements. (line 6)
5406 * Requirements, Automake: Introduction. (line 27)
5407 * Restrictions for JAVA: Java. (line 19)
5408 * RFLAGS and AM_RFLAGS: Flag Variables Ordering.
5410 * rules with multiple outputs: Multiple Outputs. (line 6)
5411 * rules, conflicting: Extending. (line 14)
5412 * rules, debugging: Debugging Make Rules.
5414 * rules, overriding: Extending. (line 27)
5415 * rx package: Public Macros. (line 111)
5416 * Scanning configure.ac: configure. (line 6)
5417 * SCRIPTS primary, defined: Scripts. (line 6)
5418 * SCRIPTS, installation directories: Scripts. (line 18)
5419 * Selecting the linker automatically: How the Linker is Chosen.
5421 * serial number and --install: aclocal Options. (line 32)
5422 * serial numbers in macros: Serials. (line 6)
5423 * Shared libraries, support for: A Shared Library. (line 6)
5424 * silent-rules: Options. (line 133)
5425 * site.exp: DejaGnu Tests. (line 26)
5426 * source tree and build tree: VPATH Builds. (line 6)
5427 * source tree, read-only: VPATH Builds. (line 90)
5428 * SOURCES primary, defined: Program Sources. (line 32)
5429 * Special Automake comment: General Operation. (line 58)
5430 * Staged installation: DESTDIR. (line 14)
5431 * std-options: Options. (line 200)
5432 * Strictness, command line: Invoking Automake. (line 37)
5433 * Strictness, defined: Strictness. (line 10)
5434 * Strictness, foreign: Strictness. (line 10)
5435 * Strictness, gnits: Strictness. (line 10)
5436 * Strictness, gnu: Strictness. (line 10)
5437 * su, before make install: Basic Installation. (line 50)
5438 * subdir-objects: Options. (line 220)
5439 * Subdirectories, building conditionally: Conditional Subdirectories.
5441 * Subdirectories, configured conditionally: Unconfigured Subdirectories.
5443 * Subdirectories, not distributed: Unconfigured Subdirectories.
5445 * Subdirectory, objects in: Program and Library Variables.
5447 * SUBDIRS and AC_SUBST: Subdirectories with AC_SUBST.
5449 * SUBDIRS and AM_CONDITIONAL: Subdirectories with AM_CONDITIONAL.
5451 * SUBDIRS, conditional: Conditional Subdirectories.
5453 * SUBDIRS, explained: Subdirectories. (line 6)
5454 * Subpackages <1>: Subpackages. (line 6)
5455 * Subpackages: Nested Packages. (line 6)
5456 * suffix .la, defined: Libtool Concept. (line 6)
5457 * suffix .lo, defined: Libtool Concept. (line 15)
5458 * SUFFIXES, adding: Suffixes. (line 6)
5459 * Support for C++: C++ Support. (line 6)
5460 * Support for Fortran 77: Fortran 77 Support. (line 6)
5461 * Support for Fortran 9x: Fortran 9x Support. (line 6)
5462 * Support for GNU Gettext: gettext. (line 6)
5463 * Support for Java: Java Support. (line 6)
5464 * Support for Objective C: Objective C Support. (line 6)
5465 * Support for Unified Parallel C: Unified Parallel C Support.
5467 * Support for Vala: Vala Support. (line 6)
5468 * tags: Tags. (line 9)
5469 * TAGS support: Tags. (line 6)
5470 * tar formats: Options. (line 232)
5471 * tar-pax: Options. (line 232)
5472 * tar-ustar: Options. (line 232)
5473 * tar-v7: Options. (line 232)
5474 * Target, install-info: Texinfo. (line 79)
5475 * Target, install-man: Man Pages. (line 32)
5476 * termios POSIX headers: Obsolete Macros. (line 53)
5477 * Test suites: Tests. (line 6)
5478 * Tests, expected failure: Simple Tests. (line 42)
5479 * Texinfo flag, EDITION: Texinfo. (line 29)
5480 * Texinfo flag, UPDATED: Texinfo. (line 29)
5481 * Texinfo flag, UPDATED-MONTH: Texinfo. (line 29)
5482 * Texinfo flag, VERSION: Texinfo. (line 29)
5483 * texinfo.tex: Texinfo. (line 64)
5484 * TEXINFOS primary, defined: Texinfo. (line 6)
5485 * third-party files and CVS: CVS. (line 140)
5486 * Third-party packages, interfacing with: Third-Party Makefiles.
5488 * timestamps and CVS: CVS. (line 28)
5489 * Transforming program names: Renaming. (line 6)
5490 * trees, source vs. build: VPATH Builds. (line 6)
5491 * true Example: true. (line 6)
5492 * underquoted AC_DEFUN: Extending aclocal. (line 33)
5493 * Unified Parallel C support: Unified Parallel C Support.
5495 * Uniform naming scheme: Uniform. (line 6)
5496 * uninstall <1>: Extending. (line 43)
5497 * uninstall <2>: Install Rules for the User.
5499 * uninstall: Standard Targets. (line 27)
5500 * uninstall-hook: Extending. (line 68)
5501 * uninstall-local: Extending. (line 43)
5502 * Unit tests: Simple Tests using parallel-tests.
5504 * Unpacking: Basic Installation. (line 27)
5505 * UPCFLAGS and AM_UPCFLAGS: Flag Variables Ordering.
5507 * UPDATED Texinfo flag: Texinfo. (line 29)
5508 * UPDATED-MONTH Texinfo flag: Texinfo. (line 29)
5509 * Use Cases for the GNU Build System: Use Cases. (line 6)
5510 * user variables: User Variables. (line 6)
5511 * ustar format: Options. (line 232)
5512 * v7 tar format: Options. (line 232)
5513 * Vala Support: Vala Support. (line 6)
5514 * variables, conflicting: Extending. (line 14)
5515 * Variables, overriding: General Operation. (line 41)
5516 * variables, reserved for the user: User Variables. (line 6)
5517 * VERSION Texinfo flag: Texinfo. (line 29)
5518 * VERSION, prevent definition: Public Macros. (line 54)
5519 * version.m4, example: Rebuilding. (line 19)
5520 * version.sh, example: Rebuilding. (line 19)
5521 * versioned binaries, installing: Extending. (line 88)
5522 * VPATH builds: VPATH Builds. (line 6)
5523 * wildcards: Wildcards. (line 6)
5524 * Windows: EXEEXT. (line 6)
5525 * yacc, multiple parsers: Yacc and Lex. (line 64)
5526 * YFLAGS and AM_YFLAGS: Flag Variables Ordering.
5528 * ylwrap: Yacc and Lex. (line 64)
5529 * zardoz example: Complete. (line 35)