home *** CD-ROM | disk | FTP | other *** search
/ Geek Gadgets 1 / ADE-1.bin / ade-dist / automake-1.1e-bin.lha / info / automake.info-1 (.txt) < prev    next >
GNU Info File  |  1996-10-12  |  51KB  |  967 lines
  1. This is Info file automake.info, produced by Makeinfo-1.64 from the
  2. input file /ade-src/fsf/automake/automake.texi.
  3. START-INFO-DIR-ENTRY
  4. * automake: (automake).        Making Makefile.in's
  5. END-INFO-DIR-ENTRY
  6.    This file documents GNU automake 1.1e
  7.    Copyright (C) 1995 Free Software Foundation, Inc.
  8.    Permission is granted to make and distribute verbatim copies of this
  9. manual provided the copyright notice and this permission notice are
  10. preserved on all copies.
  11.    Permission is granted to copy and distribute modified versions of
  12. this manual under the conditions for verbatim copying, provided that
  13. the entire resulting derived work is distributed under the terms of a
  14. permission notice identical to this one.
  15.    Permission is granted to copy and distribute translations of this
  16. manual into another language, under the above conditions for modified
  17. versions, except that this permission notice may be stated in a
  18. translation approved by the Foundation.
  19. File: automake.info,  Node: Top,  Next: Introduction,  Prev: (dir),  Up: (dir)
  20. GNU Automake
  21. ************
  22.    This file documents the GNU Automake package for creating GNU
  23. Standards-compliant Makefiles from template files.  This edition
  24. documents version 1.1e.
  25. * Menu:
  26. * Introduction::                Automake's purpose
  27. * Invoking Automake::           Creating a Makefile.in
  28. * Generalities::                General ideas
  29. * configure::                   Scanning configure.in
  30. * Top level::                   The top-level Makefile.am
  31. * Programs::                    Building programs and libraries
  32. * Other objects::               Other derived objects
  33. * Other GNU Tools::             Other GNU Tools
  34. * Documentation::               Building documentation
  35. * Install::                     What gets installed
  36. * Clean::                       What gets cleaned
  37. * Dist::                        What goes in a distribution
  38. * Tests::                       Support for test suites
  39. * Options::                     Changing Automake's behavior
  40. * Miscellaneous::               Miscellaneous rules
  41. * Extending::                   Extending Automake
  42. * Distributing::                Distributing the Makefile.in
  43. * Examples::                    Some example packages
  44. * Future::                      Some ideas for the future
  45. * Variables::                   Index of variables
  46. * Configure variables::         Index of configure variables and macros
  47. * Targets::                     Index of targets
  48. File: automake.info,  Node: Introduction,  Next: Invoking Automake,  Prev: Top,  Up: Top
  49. Introduction
  50. ************
  51.    Automake is a tool for automatically generating `Makefile.in's from
  52. files called `Makefile.am'.  The `Makefile.am' is basically a series of
  53. `make' macro definitions (with rules being thrown in occasionally).
  54. The generated `Makefile.in's are compliant with the GNU Makefile
  55. standards.
  56.    The GNU Makefile Standards Document (*note Makefile Conventions:
  57. (standards.info)Makefile Conventions.) is long, complicated, and
  58. subject to change.  The goal of Automake is to remove the burden of
  59. Makefile maintenance from the back of the individual GNU maintainer
  60. (and put it on the back of the Automake maintainer).
  61.    The typical Automake input files is simply a series of macro
  62. definitions.  Each such file is processed to create a `Makefile.in'.
  63. There should generally be one `Makefile.am' per directory of a project.
  64.    Automake does constrain a project in certain ways; for instance it
  65. assumes that the project uses Autoconf (*note The Autoconf Manual:
  66. (autoconf.info)Top.), and enforces certain restrictions on the
  67. `configure.in' contents.
  68.    `Automake' requires `perl' in order to generate the `Makefile.in's.
  69. However, the distributions created by Automake are fully GNU
  70. standards-compliant, and do not require `perl' in order to be built.
  71.    Mail suggestions and bug reports for Automake to
  72. bug-gnu-utils@prep.ai.mit.edu.
  73. File: automake.info,  Node: Invoking Automake,  Next: Generalities,  Prev: Introduction,  Up: Top
  74. Creating a `Makefile.in'
  75. ************************
  76.    To create all the `Makefile.in's for a package, run the `automake'
  77. program in the top level directory, with no arguments.  `automake' will
  78. automatically find each appropriate `Makefile.am' (by scanning
  79. `configure.in'; *note configure::.) and generate the corresponding
  80. `Makefile.in'.
  81.    You can optionally give `automake' an argument; `.am' is appended to
  82. the argument and the result is used as the name of the input file.
  83. This feature is generally only used to automatically rebuild an
  84. out-of-date `Makefile.in'.  Note that `automake' must always be run
  85. from the topmost directory of a project, even if being used to
  86. regenerate the `Makefile.in' in some subdirectory.  This is necessary
  87. because `automake' must scan `configure.in', and because `automake'
  88. uses the knowledge that a `Makefile.in' is in a subdirectory to change
  89. its behavior in some cases.
  90.    `automake' accepts the following options:
  91. `--add-missing'
  92.      Automake requires certain common files to exist in certain
  93.      situations; for instance `config.guess' is required if
  94.      `configure.in' runs `AC_CANONICAL_HOST'.  Automake is distributed
  95.      with several of these files; this option will cause the missing
  96.      ones to be automatically added to the package, whenever possible.
  97.      In general if Automake tells you a file is missing, try using this
  98.      option.
  99. `--amdir=DIR'
  100.      Look for Automake data files in directory DIR instead of in the
  101.      installation directory.  This is typically used for debugging.
  102. `--build-dir=DIR'
  103.      Tell Automake where the build directory is.  This option is used
  104.      when including dependencies into a `Makefile.in' generated by `make
  105.      dist'; it should not be used otherwise.
  106. `--foreign'
  107.      An alias for `--strictness=foreign'.
  108. `--gnits'
  109.      An alias for `--strictness=gnits'.
  110. `--gnu'
  111.      An alias for `--strictness=gnu'.
  112. `--help'
  113.      Print a summary of the command line options and exit.
  114. `--include-deps'
  115.      Include all automatically generated dependency information (*note
  116.      Dependencies::.) in the generated `Makefile.in'.  This is
  117.      generally done when making a distribution; see *Note Dist::.
  118. `-o DIR'
  119. `--output-dir=DIR'
  120.      Put the generated `Makefile.in' in the directory DIR.  Ordinarily
  121.      each `Makefile.in' is created in the directory of the
  122.      corresponding `Makefile.am'.  This option is used when making
  123.      distributions.
  124. `--srcdir-name=DIR'
  125.      Tell Automake the name of the source directory used in the current
  126.      build.  This option is used when including dependencies into a
  127.      `Makefile.in' generated by `make dist'; it should not be used
  128.      otherwise.
  129. `-s LEVEL'
  130. `--strictness=LEVEL'
  131.      Set the global strictness to LEVEL; this can be overridden in each
  132.      `Makefile.am' if required.  *Note Generalities:: for more
  133.      information.
  134. `--verbose'
  135.      Cause Automake to print information about which files are being
  136.      read or created.
  137. `--version'
  138.      Print the version number of Automake and exit.
  139. File: automake.info,  Node: Generalities,  Next: configure,  Prev: Invoking Automake,  Up: Top
  140. General ideas
  141. *************
  142.    There are a few basic ideas that will help understand how Automake
  143. works.
  144. * Menu:
  145. * General Operation::           General operation of Automake
  146. * Depth::                       The kinds of packages
  147. * Strictness::                  Standards conformance checking
  148. * Uniform::                     The Uniform Naming Scheme
  149. * Canonicalization::            How derived variables are named
  150. File: automake.info,  Node: General Operation,  Next: Depth,  Up: Generalities
  151. General Operation
  152. =================
  153.    Automake essentially works by reading a `Makefile.am' and generating
  154. a `Makefile.in'.
  155.    The macro definitions and targets in the `Makefile.am' are copied
  156. into the generated file.  This allows you to add essentially arbitrary
  157. code into the generated `Makefile.in'.  For instance the Automake
  158. distribution includes a non-standard `cvs-dist' target, which the
  159. Automake maintainer uses to make distributions from his source control
  160. system.
  161.    Note that GNU make extensions are not recognized by Automake.  Using
  162. such extensions in a `Makefile.am' will lead to errors or confusing
  163. behavior.
  164.    Automake tries to group comments with adjoining targets (or variable
  165. definitions) in an intelligent way.
  166.    A target defined in `Makefile.am' generally overrides any such
  167. target of a similar name that would be automatically generated by
  168. `automake'.  Although this is a supported feature, it is generally best
  169. to avoid making use of it, as sometimes the generated rules are very
  170. particular.
  171.    When examining a variable definition, Automake will recursively
  172. examine variables referenced in the definition.  Eg if Automake is
  173. looking at the content of `foo_SOURCES' in this snippet
  174.      xs = a.c b.c
  175.      foo_SOURCES = c.c $(xs)
  176.    it would use the files `a.c', `b.c', and `c.c' as the contents of
  177. `foo_SOURCES'.
  178.    Automake also allows a form of comment which is *not* copied into
  179. the output; all lines beginning with `##' are completely ignored by
  180. Automake.
  181.    It is customary to make the first line of `Makefile.am' read:
  182.      ## Process this file with automake to produce Makefile.in
  183. File: automake.info,  Node: Depth,  Next: Strictness,  Prev: General Operation,  Up: Generalities
  184. Depth
  185. =====
  186.    `automake' supports three kinds of directory hierarchy: "flat",
  187. "shallow", and "deep".
  188.    A "flat" package is one in which all the files are in a single
  189. directory.  The `Makefile.am' for such a package by definition lacks a
  190. `SUBDIRS' macro.  An example of such a package is `termutils'.
  191.    A "deep" package is one in which all the source lies in
  192. subdirectories; the top level directory contains mainly configuration
  193. information.  GNU cpio is a good example of such a package, as is GNU
  194. `tar'.  The top level `Makefile.am' for a deep package will contain a
  195. `SUBDIRS' macro, but no other macros to define objects which are built.
  196.    A "shallow" package is one in which the primary source resides in
  197. the top-level directory, while various parts (typically libraries)
  198. reside in subdirectories.  `automake' is one such package (as is GNU
  199. `make', which does not currently use `automake').
  200. File: automake.info,  Node: Strictness,  Next: Uniform,  Prev: Depth,  Up: Generalities
  201. Strictness
  202. ==========
  203.    While Automake is intended to be used by maintainers of GNU
  204. packages, it does make some effort to accommodate those who wish to use
  205. it, but do not want to use all the GNU conventions.
  206.    To this end, Automake supports three levels of "strictness" - the
  207. strictness indicating how stringently Automake should check standards
  208. conformance.
  209.    The valid strictness levels are:
  210. `foreign'
  211.      Automake will check for only those things which are absolutely
  212.      required for proper operations.  For instance, whereas GNU
  213.      standards dictate the existence of a `NEWS' file, it will not be
  214.      required in this mode.  The name comes from the fact that Automake
  215.      is intended to be used for GNU programs; these relaxed rules are
  216.      not the standard mode of operation.
  217. `gnu'
  218.      Automake will check - as much as possible - for compliance to the
  219.      GNU standards for packages.  This is the default.
  220. `gnits'
  221.      Automake will check for compliance to the as-yet-unwritten GNITS
  222.      standards.  These are based on the GNU standards, but are even more
  223.      detailed.  Unless you are a GNITS standards contributor, it is
  224.      recommended that you avoid this option until such time as the GNITS
  225.      standard is actually published.
  226. File: automake.info,  Node: Uniform,  Next: Canonicalization,  Prev: Strictness,  Up: Generalities
  227. The Uniform Naming Scheme
  228. =========================
  229.    Automake variables generally follow a uniform naming scheme that
  230. makes it easy to decide how programs (and other derived objects) are
  231. built, and how they are installed.  This scheme also supports
  232. `configure' time determination of what should be built.
  233.    At `make' time, certain variables are used to determine which
  234. objects are to be built.  These variables are called "primary"
  235. variables.  For instance, the primary variable `PROGRAMS' holds a list
  236. of programs which are to be compiled and linked.
  237.    A different set of variables is used to decide where the built
  238. objects should be installed.  These variables are named after the
  239. primary variables, but have a prefix indicating which standard
  240. directory should be used as the installation directory.  The standard
  241. directory names are given in the GNU standards (*note Directory
  242. Variables: (standards.info)Directory Variables.).  `automake' extends
  243. this list with `pkglibdir', `pkgincludedir', and `pkgdatadir'; these
  244. are the same as the non-`pkg' versions, but with `@PACKAGE@' appended.
  245.    For each primary, there is one additional variable named by
  246. prepending `EXTRA_' to the primary name.  This variable is used to list
  247. objects which may or may not be built, depending on what `configure'
  248. decides.  This variable is required because Automake must know the
  249. entire list of objects to be built in order to generate a `Makefile.in'
  250. that will work in all cases.
  251.    For instance, `cpio' decides at configure time which programs are
  252. built.  Some of the programs are installed in `bindir', and some are
  253. installed in `sbindir':
  254.      EXTRA_PROGRAMS = mt rmt
  255.      bin_PROGRAMS = cpio pax
  256.      sbin_PROGRAMS = @PROGRAMS@
  257.    Defining a primary variable is an error.
  258.    Note that the common `dir' suffix is left off when constructing the
  259. variable names; thus one writes `bin_PROGRAMS' and not
  260. `bindir_PROGRAMS'.
  261.    Not every sort of object can be installed in every directory.
  262. Automake will flag those attempts it finds in error.  Automake will
  263. also diagnose obvious misspellings in directory names.
  264.    Sometimes the standard directories - even as augmented by Automake -
  265. are not enough.  In particular it is sometimes useful, for clarity, to
  266. install objects in a subdirectory of some predefined directory.  To this
  267. end, Automake allows you to extend the list of possible installation
  268. directories.  A given prefix (eg `zar') is valid if a variable of the
  269. same name with `dir' appended is defined (eg `zardir').
  270.    For instance, until HTML support is part of Automake, you could use
  271. this to install raw HTML documentation:
  272.      htmldir = $(prefix)/html
  273.      html_DATA = automake.html
  274.    The special prefix `noinst' indicates that the objects in question
  275. should not be installed at all.
  276.    The special prefix `check' indicates that the objects in question
  277. should not be built until the `make check' command is run.
  278.    Possible primary names are `PROGRAMS', `LIBRARIES', `LISP',
  279. `SCRIPTS', `DATA', `HEADERS', `MANS', and `TEXINFOS'.
  280. File: automake.info,  Node: Canonicalization,  Prev: Uniform,  Up: Generalities
  281. How derived variables are named
  282. ===============================
  283.    Sometimes a Makefile variable name is derived from some text the user
  284. supplies.  For instance program names are rewritten into Makefile macro
  285. names.  Automake canonicalizes this text, so that it does not have to
  286. follow Makefile variable naming rules.  All characters in the name
  287. except for letters, numbers, and the underscore are turned into
  288. underscores when making macro references.  Eg, if your program is named
  289. `sniff-glue', the derived variable name would be `sniff_glue_SOURCES',
  290. not `sniff-glue_SOURCES'.
  291. File: automake.info,  Node: configure,  Next: Top level,  Prev: Generalities,  Up: Top
  292. Scanning `configure.in'
  293. ***********************
  294.    Automake scans the package's `configure.in' to determine certain
  295. information about the package.  Some `autoconf' macros are required and
  296. some variables must be defined in `configure.in'.  Automake will also
  297. use information from `configure.in' to further tailor its output.
  298. * Menu:
  299. * Requirements::                Configuration requirements
  300. * Optional::                    Other things Automake recognizes
  301. * Invoking aclocal::            Auto-generating aclocal.m4
  302. * Macros::                      Autoconf macros supplied with Automake
  303. * Extending aclocal::           Writing your own aclocal macros
  304. File: automake.info,  Node: Requirements,  Next: Optional,  Up: configure
  305. Configuration requirements
  306. ==========================
  307.    The simplest way to meet the basic Automake requirements is to use
  308. the macro `AM_INIT_AUTOMAKE' (FIXME: xref).  But if you prefer, you can
  309. do the required steps by hand:
  310.    * Define the variables `PACKAGE' and `VERSION' with `AC_SUBST'.
  311.      `PACKAGE' should be the name of the package as it appears when
  312.      bundled for distribution.  For instance, Automake defines `PACKAGE'
  313.      to be `automake'.  `VERSION' should be the version number of the
  314.      release that is being developed.  We recommend that you make
  315.      `configure.in' the only place in your package where the version
  316.      number is defined; this makes releases simpler.
  317.      Automake doesn't do any interpretation of `PACKAGE' or `VERSION',
  318.      except in `Gnits' mode (FIXME xref).
  319.    * Use the macro `AC_ARG_PROGRAM' if a program or script is installed.
  320.    * Use `AC_PROG_MAKE_SET' if the package is not flat.
  321.    * Use `AM_PROG_INSTALL' if any scripts (*note Scripts::.) are
  322.      installed by the package.  Otherwise, use `AC_PROG_INSTALL'.
  323.    Here are the other macros which Automake requires but which are not
  324. run by `AM_INIT_AUTOMAKE':
  325. `AC_OUTPUT'
  326.      Automake uses this to determine which files to create.  Listed
  327.      files named `Makefile' are treated as `Makefile's.  Other listed
  328.      files are treated differently.  Currently the only difference is
  329.      that a `Makefile' is removed by `make distclean', while other files
  330.      are removed by `make clean'.
  331. File: automake.info,  Node: Optional,  Next: Invoking aclocal,  Prev: Requirements,  Up: configure
  332. Other things Automake recognizes
  333. ================================
  334.    Automake will also recognize the use of certain macros and tailor the
  335. generated `Makefile.in' appropriately.  Currently recognized macros and
  336. their effects are:
  337. `AC_CONFIG_HEADER'
  338.      Automake will generate rules to automatically regenerate the config
  339.      header.  If you do use this macro, you must create the file
  340.      `stamp-h.in' in your source directory.  It can be empty.  Also, the
  341.      `AC_OUTPUT' command in `configure.in' must create `stamp-h', eg:
  342.           AC_OUTPUT(Makefile,
  343.           [test -z "$CONFIG_HEADERS" || echo timestamp > stamp-h])
  344.      Note that Automake does not currently currently check to make sure
  345.      the `AC_OUTPUT' command is correct.  Hopefully a future version of
  346.      `autoconf' will let Automake handle this automatically.
  347. `AC_CONFIG_AUX_DIR'
  348.      Automake will look for various helper scripts, such as
  349.      `mkinstalldirs', in the directory named in this macro invocation.
  350.      If not seen, the scripts are looked for in their "standard"
  351.      locations (either the top source directory, or in the source
  352.      directory corresponding to the current `Makefile.am', whichever is
  353.      appropriate).  FIXME: give complete list of things looked for in
  354.      this directory
  355. `AC_PATH_XTRA'
  356.      Automake will insert definitions for the variables defined by
  357.      `AC_PATH_XTRA' into each `Makefile.in' that builds a C program or
  358.      library.
  359. `AC_CANONICAL_HOST'
  360. `AC_CANONICAL_SYSTEM'
  361. `AC_CHECK_TOOL'
  362.      Automake will ensure that `config.guess' and `config.sub' exist.
  363. `AC_FUNC_ALLOCA'
  364. `AC_FUNC_GETLOADAVG'
  365. `AC_FUNC_MEMCMP'
  366. `AC_STRUCT_ST_BLOCKS'
  367. `AM_FUNC_FNMATCH'
  368. `AM_FUNC_STRTOD'
  369. `AC_REPLACE_FUNCS'
  370. `AC_REPLACE_GNU_GETOPT'
  371. `AM_WITH_REGEX'
  372.      Automake will ensure that the appropriate source files are part of
  373.      the distribution, and will ensure that the appropriate
  374.      dependencies are generated for these objects.  *Note A Library::
  375.      for more information.
  376. `LIBOBJS'
  377.      Automake will detect statements which put `.o' files into
  378.      `LIBOBJS', and will treat these additional files as if they were
  379.      discovered via `AC_REPLACE_FUNCS'.
  380. `AC_PROG_RANLIB'
  381.      This is required if any libraries are built in the package.
  382. `AC_PROG_CXX'
  383.      This is required if any C++ source is included.
  384. `AC_PROG_YACC'
  385.      If a Yacc source file is seen, then you must either use this macro
  386.      or declare the variable `YACC' in `configure.in'.  The former is
  387.      preferred.
  388. `AC_DECL_YYTEXT'
  389.      This macro is required if there is Yacc source in the package.
  390. `AC_PROG_LEX'
  391.      If a Lex source file is seen, then this macro must be used.
  392. `ALL_LINGUAS'
  393.      If Automake sees that this variable is set in `configure.in', it
  394.      will check the `po' directory to ensure that all the named `.po'
  395.      files exist, and that all the `.po' files that exist are named.
  396. `AM_C_PROTOTYPES'
  397.      This is required when using automatic de-ANSI-fication, see *Note
  398.      ANSI::.
  399. `ud_GNU_GETTEXT'
  400.      This macro is required for packages which use GNU gettext (*note
  401.      gettext::.).  It is distributed with gettext.  Automake uses this
  402.      macro to ensure that the package meets some of gettext's
  403.      requirements.
  404. `AM_MAINTAINER_MODE'
  405.      This macro adds a `--enable-maintainer-mode' option to
  406.      `configure'.  If this is used, `automake' will cause
  407.      "maintainer-only" rules to be turned off by default in the
  408.      generated `Makefile.in's.  This macro is disallowed in `Gnits'
  409.      mode.  FIXME xref.
  410. File: automake.info,  Node: Invoking aclocal,  Next: Macros,  Prev: Optional,  Up: configure
  411. Auto-generating aclocal.m4
  412. ==========================
  413.    The `aclocal' program will automatically generate `aclocal.m4' files
  414. based on the contents of `configure.in'.
  415.    ... explain why on earth you'd want to do this
  416.    `aclocal' accepts the following options:
  417. `--acdir=DIR'
  418.      Look for the macro files in DIR instead of the installation
  419.      directory.  This is typically used for debugging.
  420. `--help'
  421.      Print a summary of the command line options and exit.
  422. `--output=FILE'
  423.      Cause the output to be put into FILE instead of `aclocal.m4'.
  424. `--verbose'
  425.      Print the names of the files it examines.
  426. `--version'
  427.      Print the version number of Automake and exit.
  428. File: automake.info,  Node: Macros,  Next: Extending aclocal,  Prev: Invoking aclocal,  Up: configure
  429. Autoconf macros supplied with Automake
  430. ======================================
  431. `AM_FUNC_FNMATCH'
  432.      If the `fnmatch' function is not available, or does not work
  433.      correctly (like the one on SunOS 5.4), add `fnmatch.o' to output
  434.      variable `LIBOBJS'.
  435. `AM_FUNC_STRTOD'
  436.      If the `strtod' function is not available, or does not work
  437.      correctly (like the one on SunOS 5.4), add `strtod.o' to output
  438.      variable `LIBOBJS'.
  439. `AM_C_PROTOTYPES'
  440. `AM_TIOCGWINSZ_NEEDS_IOCTL'
  441. `AM_INIT_AUTOMAKE'
  442. `AM_MAINTAINER_MODE'
  443. `AM_PATH_LISPDIR'
  444. `AM_PROG_CC_STDC'
  445. `AM_PROG_INSTALL'
  446. `AM_SANITY_CHECK_CC'
  447. `AM_SYS_POSIX_TERMIOS'
  448. `AM_TYPE_PTRDIFF_T'
  449. `AM_WITH_DMALLOC'
  450. `AM_WITH_REGEX'
  451. File: automake.info,  Node: Extending aclocal,  Prev: Macros,  Up: configure
  452. Writing your own aclocal macros
  453. ===============================
  454.    ... explain format of macro files ... explain how to get your own
  455. macros installed (using acinstall) ... explain situations where this is
  456. actually useful (eg gettext)
  457. File: automake.info,  Node: Top level,  Next: Programs,  Prev: configure,  Up: Top
  458. The top-level `Makefile.am'
  459. ***************************
  460.    In non-flat packages, the top level `Makefile.am' must tell Automake
  461. which subdirectories are to be built.  This is done via the `SUBDIRS'
  462. variable.
  463.    The `SUBDIRS' macro holds a list of subdirectories in which building
  464. of various sorts can occur.  Many targets (eg `all') in the generated
  465. `Makefile' will run both locally and in all specified subdirectories.
  466. Note that the directories listed in `SUBDIRS' are not required to
  467. contain `Makefile.am's; only `Makefile's (after configuration).  This
  468. allows inclusion of libraries from packages which do not use Automake
  469. (such as `gettext').
  470.    In a deep package, the top-level `Makefile.am' is often very short.
  471. For instance, here is the `Makefile.am' from the textutils distribution:
  472.      SUBDIRS = lib src doc man
  473.      EXTRA_DIST = @README_ALPHA@
  474.    `SUBDIRS' can contain configure substitutions (eg `@DIRS@');
  475. Automake itself does not actually examine the contents of this variable.
  476.    If `SUBDIRS' is defined, then your `configure.in' must include
  477. `AC_PROG_MAKE_SET'.
  478.    The use of `SUBDIRS' is not restricted to just the top-level
  479. `Makefile.am'.  Automake can be used to construct packages of arbitrary
  480. depth.
  481. File: automake.info,  Node: Programs,  Next: Other objects,  Prev: Top level,  Up: Top
  482. Building Programs and Libraries
  483. *******************************
  484.    A large part of Automake's functionality is dedicated to making it
  485. easy to build C programs and libraries.
  486. * Menu:
  487. * A Program::                   Building a program
  488. * A Library::                   Building a library
  489. * LIBOBJS::                     Special handling for LIBOBJS and ALLOCA
  490. * Program variables::           Variables used when building a program
  491. * Yacc and Lex::                Yacc and Lex support
  492. * C++::                         C++ and other languages
  493. * ANSI::                        Automatic de-ANSI-fication
  494. * Dependencies::                Automatic dependency tracking
  495. File: automake.info,  Node: A Program,  Next: A Library,  Up: Programs
  496. Building a program
  497. ==================
  498.    In a directory containing source that gets built into a program (as
  499. opposed to a library), the `PROGRAMS' primary is used.  Programs can be
  500. installed in `bindir', `sbindir', `libexecdir', `pkglibdir', or not at
  501.    For instance:
  502.      bin_PROGRAMS = hello
  503.    In this simple case, the resulting `Makefile.in' will contain code
  504. to generate a program named `hello'.  The variable `hello_SOURCES' is
  505. used to specify which source files get built into an executable:
  506.      hello_SOURCES = hello.c
  507.    This causes `hello.c' to be compiled into `hello.o', and then linked
  508. to produce `hello'.
  509.    If `prog_SOURCES' is needed, but not specified, then it defaults to
  510. the single file `prog.c'.  In the example above, the definition of
  511. `hello_SOURCES' is actually redundant.
  512.    Multiple programs can be built in a single directory.  Multiple
  513. programs can share a single source file.  The source file must be
  514. listed in each `_SOURCES' definition.
  515.    Header files listed in a `_SOURCES' definition will be included in
  516. the distribution but otherwise ignored.  In case it isn't obvious, you
  517. should not include the header file generated by `configure' in an
  518. `_SOURCES' variable; this file should not be distributed.  Lex (`.l')
  519. and yacc (`.y') files can also be listed; support for these should work
  520. but is still preliminary.
  521.    Sometimes it is useful to determine the programs that are to be
  522. built at configure time.  For instance, GNU `cpio' only builds `mt' and
  523. `rmt' under special circumstances.
  524.    In this case, you must notify `Automake' of all the programs that
  525. can possibly be built, but at the same time cause the generated
  526. `Makefile.in' to use the programs specified by `configure'.  This is
  527. done by having `configure' substitute values into each `_PROGRAMS'
  528. definition, while listing all optionally built programs in
  529. `EXTRA_PROGRAMS'.
  530.    If you need to link against libraries that are not found by
  531. `configure', you can use `LDADD' to do so.  This variable actually can
  532. be used to add any options to the linker command line.
  533.    Sometimes, multiple programs are built in one directory but do not
  534. share the same link-time requirements.  In this case, you can use the
  535. `PROG_LDADD' variable (where PROG is the name of the program as it
  536. appears in some `_PROGRAMS' variable, and usually written in lowercase)
  537. to override the global `LDADD'.  (If this variable exists for a given
  538. program, then that program is not linked using `LDADD'.)
  539.    For instance, in GNU cpio, `pax', `cpio', and `mt' are linked
  540. against the library `libcpio.a'.  However, `rmt' is built in the same
  541. directory, and has no such link requirement.  Also, `mt' and `rmt' are
  542. only built on certain architectures.  Here is what cpio's
  543. `src/Makefile.am' looks like (abridged):
  544.      bin_PROGRAMS = cpio pax @MT@
  545.      libexec_PROGRAMS = @RMT@
  546.      EXTRA_PROGRAMS = mt rmt
  547.      
  548.      LDADD = ../lib/libcpio.a @INTLLIBS@
  549.      rmt_LDADD =
  550.      
  551.      cpio_SOURCES = ...
  552.      pax_SOURCES = ...
  553.      mt_SOURCES = ...
  554.      rmt_SOURCES = ...
  555.    It is also occasionally useful to have a program depend on some other
  556. target which is not actually part of that program.  This can be done
  557. using the `prog_DEPENDENCIES' variable.  Each program depends on the
  558. contents of such a variable, but no further interpretation is done.
  559.    If `prog_DEPENDENCIES' is not supplied, it is computed by Automake.
  560. The automatically-assigned value is the contents of `prog_LDADD' with
  561. all the `-l' and `-L' options removed.  Be warned that `configure'
  562. substitutions are preserved; this can lead to bad dependencies if you
  563. are not careful.
  564. File: automake.info,  Node: A Library,  Next: LIBOBJS,  Prev: A Program,  Up: Programs
  565. Building a library
  566. ==================
  567.    Building a library is much like building a program.  In this case,
  568. the name of the primary is `LIBRARIES'.  Libraries can be installed in
  569. `libdir' or `pkglibdir'.
  570.    Each `_LIBRARIES' variable is a list of the base names of libraries
  571. to be built.  For instance to create a library named `libcpio.a', but
  572. not install it, you would write:
  573.      noinst_LIBRARIES = cpio
  574.    The sources that go into a library are determined exactly as they are
  575. for programs, via the `_SOURCES' variables.  Note that programs and
  576. libraries share a namespace, so one cannot have a program (`lob') and a
  577. library (`liblob.a') with the same name in one directory.
  578.    Extra objects can be added to a library using the `library_LIBADD'
  579. variable.  This should be used for objects determined by `configure'.
  580. Again from cpio:
  581.      cpio_LIBADD = @LIBOBJS@ @ALLOCA@
  582. File: automake.info,  Node: LIBOBJS,  Next: Program variables,  Prev: A Library,  Up: Programs
  583. Special handling for LIBOBJS and ALLOCA
  584. =======================================
  585.    Automake explicitly recognizes the use of `@LIBOBJS@' and
  586. `@ALLOCA@', and uses this information, plus the list of `LIBOBJS' files
  587. derived from `configure.in' to automatically include the appropriate
  588. source files in the distribution (*note Dist::.).  These source files
  589. are also automatically handled in the dependency-tracking scheme, see
  590. *Note Dependencies::.
  591.    `@LIBOBJS@' and `@ALLOCA@' are specially recognized in any `_LDADD'
  592. or `_LIBADD' variable.
  593. File: automake.info,  Node: Program variables,  Next: Yacc and Lex,  Prev: LIBOBJS,  Up: Programs
  594. Variables used when building a program
  595. ======================================
  596.    Occasionally it is useful to know which `Makefile' variables
  597. Automake uses for compilations; for instance you might need to do your
  598. own compilation in some special cases.
  599.    Some variables are inherited from Autoconf; these are `CC',
  600. `CFLAGS', `CPPFLAGS', `DEFS', `LDFLAGS', and `LIBS'.
  601.    There are some additional variables which Automake itself defines:
  602. `INCLUDES'
  603.      A list of `-I' options.  This can be set in your `Makefile.am' if
  604.      you have special directories you want to look in.
  605. `COMPILE'
  606.      This is the command used to actually compile a C source file.  The
  607.      filename is appended to form the complete command line.
  608. `LINK'
  609.      This is the command used to actually link a C program.
  610. File: automake.info,  Node: Yacc and Lex,  Next: C++,  Prev: Program variables,  Up: Programs
  611. Yacc and Lex support
  612. ====================
  613.    Automake has somewhat idiosyncratic support for Yacc and Lex.
  614. FIXME: describe it here.
  615. File: automake.info,  Node: C++,  Next: ANSI,  Prev: Yacc and Lex,  Up: Programs
  616. C++ and other languages
  617. =======================
  618.    Automake includes full support for C++, and rudimentary support for
  619. other languages.  Support for other languages will be improved based on
  620. demand.
  621.    Any package including C++ code must use `AC_PROG_CXX' in its
  622. `configure.in'.
  623.    A few additional variables are defined when a C++ source file is
  624. seen:
  625. `CXX'
  626.      The name of the C++ compiler.
  627. `CXXFLAGS'
  628.      Any flags to pass to the C++ compiler.
  629. `CXXCOMPILE'
  630.      The command used to actually compile a C++ source file.  The file
  631.      name is appended to form the complete command line.
  632. `CXXLINK'
  633.      The command used to actually link a C++ program.
  634. File: automake.info,  Node: ANSI,  Next: Dependencies,  Prev: C++,  Up: Programs
  635. Automatic de-ANSI-fication
  636. ==========================
  637.    Although the GNU standards prohibit it, some GNU programs are
  638. written in ANSI C; see FIXME.  This is possible because each source
  639. file can be "de-ANSI-fied" before the actual compilation takes place.
  640.    If the `Makefile.am' variable `AUTOMAKE_OPTIONS' (*Note Options::)
  641. contains the option `ansi2knr' then code to handle de-ANSI-fication is
  642. inserted into the generated `Makefile.in'.
  643.    This causes each source file to be treated as ANSI C.  If an ANSI C
  644. compiler is available, it is used.
  645.    This support requires the source files `ansi2knr.c' and `ansi2knr.1'
  646. to be in the same directory as the ANSI C source; these files are
  647. distributed with Automake.  Also, the package `configure.in' must call
  648. the macro `AM_C_PROTOTYPES'.
  649.    Automake also handles finding the `ansi2knr' support files in some
  650. other directory in the current package.  This is done by prepending the
  651. relative path to the appropriate directory to the `ansi2knr' option.
  652. For instance, suppose the package has ANSI C code in the `src' and
  653. `lib' subdirs.  The files `ansi2knr.c' and `ansi2knr.1' appear in
  654. `lib'.  Then this could appear in `src/Makefile.am':
  655.      AUTOMAKE_OPTIONS = ../lib/ansi2knr
  656.    Note that the directory holding the `ansi2knr' support files must be
  657. built before all other directories using these files.  Automake does
  658. not currently check that this is the case.
  659. File: automake.info,  Node: Dependencies,  Prev: ANSI,  Up: Programs
  660. Automatic dependency tracking
  661. =============================
  662.    As a developer it is often painful to continually update the
  663. `Makefile.in' whenever the include-file dependencies change in a
  664. project.  `automake' supplies a way to automatically track dependency
  665. changes, and distribute the dependencies in the generated `Makefile.in'.
  666.    Currently this support requires the use of GNU `make' and `gcc'.  It
  667. might become possible in the future to supply a different dependency
  668. generating program, if there is enough demand.
  669.    This mode is enabled by default if any C program or library is
  670. defined in the current directory.
  671.    When you decide to make a distribution, the `dist' target will
  672. re-run `automake' with the `--include-deps' option.  This causes the
  673. previously generated dependencies to be inserted into the generated
  674. `Makefile.in', and thus into the distribution.  `--include-deps' also
  675. turns off inclusion of the dependency generation code.
  676.    This mode can be suppressed by putting `no-dependencies' in the
  677. variable `AUTOMAKE_OPTIONS'.
  678.    If you unpack a distribution made by `make dist', and you want to
  679. turn on the dependency-tracking code again, simply run `automake' with
  680. no arguments.
  681. File: automake.info,  Node: Other objects,  Next: Other GNU Tools,  Prev: Programs,  Up: Top
  682. Other Derived Objects
  683. *********************
  684.    Automake can handle derived objects which are not C programs.
  685. Sometimes the support for actually building such objects must be
  686. explicitly supplied, but Automake will still automatically handle
  687. installation and distribution.
  688. * Menu:
  689. * Scripts::                     Executable scripts
  690. * Headers::                     Header files
  691. * Data::                        Architecture-independent data files
  692. * Sources::                     Derived sources
  693. File: automake.info,  Node: Scripts,  Next: Headers,  Up: Other objects
  694. Executable Scripts
  695. ==================
  696.    It is possible to define and install programs which are scripts.
  697. Such programs are listed using the `SCRIPTS' primary name.  `automake'
  698. doesn't define any dependencies for scripts; the `Makefile.am' should
  699. include the appropriate rules.
  700.    `automake' does not assume that scripts are derived objects; such
  701. objects must be deleted by hand; see *Note Clean:: for more information.
  702.    `automake' itself is a script that is generated at configure time
  703. from `automake.in'.  Here is how this is handled:
  704.      bin_SCRIPTS = automake
  705.    Since `automake' appears in the `AC_OUTPUT' macro, a target for it
  706. is automatically generated.
  707.    Script objects can be installed in `bindir', `sbindir',
  708. `libexecdir', or `pkgdatadir'.
  709. File: automake.info,  Node: Headers,  Next: Data,  Prev: Scripts,  Up: Other objects
  710. Header files
  711. ============
  712.    Header files are specified by the `HEADERS' family of variables.
  713. Generally header files are not installed, so the `noinst_HEADERS'
  714. variable will be the most used.
  715.    All header files must be listed somewhere; missing ones will not
  716. appear in the distribution.  Often it is clearest to list uninstalled
  717. headers with the rest of the sources for a program.  *Note A Program::.
  718. Headers listed in a `_SOURCES' variable need not be listed in any
  719. `_HEADERS' variable.
  720.    Headers can be installed in `includedir', `oldincludedir', or
  721. `pkgincludedir'.
  722. File: automake.info,  Node: Data,  Next: Sources,  Prev: Headers,  Up: Other objects
  723. Architecture-independent data files
  724. ===================================
  725.    Automake supports the installation of miscellaneous data files using
  726. the `DATA' family of variables.
  727.    Such data can be installed in the directories `datadir',
  728. `sysconfdir', `sharedstatedir', `localstatedir', or `pkgdatadir'.
  729.    All such data files are included in the distribution.
  730.    Here is how `automake' installs its auxiliary data files:
  731.      pkgdata_DATA = clean-kr.am clean.am compile-kr.am compile-vars.am \
  732.      compile.am data.am depend.am dist-subd-top.am dist-subd-vars.am \
  733.      dist-subd.am dist-vars.am dist.am footer.am header-vars.am header.am \
  734.      libscripts.am libprograms.am libraries-vars.am libraries.am library.am \
  735.      mans-vars.am mans.am packagedata.am program.am programs.am remake-hdr.am \
  736.      remake-subd.am remake.am scripts.am subdirs.am tags.am tags-subd.am \
  737.      texinfos-vars.am texinfos.am hack-make.sed nl-remove.sed
  738. File: automake.info,  Node: Sources,  Prev: Data,  Up: Other objects
  739. Built sources
  740. =============
  741.    Occasionally a file which would otherwise be called "source" (eg a C
  742. `.h' file) is actually derived from some other file.  Such files should
  743. be listed in the `BUILT_SOURCES' variable.
  744.    Files listed in `BUILT_SOURCES' are built before any automatic
  745. dependency tracking is done.  Built sources are included in a
  746. distribution.
  747. File: automake.info,  Node: Other GNU Tools,  Next: Documentation,  Prev: Other objects,  Up: Top
  748. Other GNU Tools
  749. ***************
  750.    Since Automake is primarily intended to generate `Makefile.in's for
  751. use in GNU programs, it tries hard to interoperatoe with other GNU
  752. tools.
  753. * Menu:
  754. * Emacs Lisp::                  Emacs Lisp
  755. * gettext::                     Gettext
  756. File: automake.info,  Node: Emacs Lisp,  Next: gettext,  Up: Other GNU Tools
  757. Emacs Lisp
  758. ==========
  759.    Automake provides some support for Emacs Lisp.  The `LISP' primary
  760. is used to hold a list of `.el' files.  Possible prefixes for this
  761. primary are `lisp_' and `noinst_'.  Note that if `lisp_LISP' is
  762. defined, then `configure.in' must run `AM_PATH_LISPDIR' (fixme xref).
  763.    By default Automake will byte-compile all Emacs Lisp source files
  764. using the Emacs found by `AM_PATH_LISPDIR'.  If you wish to avoid
  765. byte-compiling, simply define the variable `ELCFILES' to be empty.
  766. File: automake.info,  Node: gettext,  Prev: Emacs Lisp,  Up: Other GNU Tools
  767. Gettext
  768. =======
  769.    If `ud_GNU_GETTEXT' is seen in `configure.in', then Automake turns
  770. on support for GNU gettext, a message catalog system for
  771. internationalization (*note GNU Gettext: (gettext.info)GNU Gettext.).
  772.    The `gettext' support in Automake requires the addition of two
  773. subdirectories to the package, `intl' and `po'.  Automake ensure that
  774. these directories exist and are mentioned in `SUBDIRS'.
  775.    Furthermore, Automake checks that the definition of `ALL_LINGUAS' in
  776. `configure.in' corresponds to all the valid `.po' files, and nothing
  777. more.
  778. File: automake.info,  Node: Documentation,  Next: Install,  Prev: Other GNU Tools,  Up: Top
  779. Building documentation
  780. **********************
  781.    Currently Automake provides support for Texinfo and man pages.
  782. * Menu:
  783. * Texinfo::                     Texinfo
  784. * Man pages::                   Man pages
  785. File: automake.info,  Node: Texinfo,  Next: Man pages,  Up: Documentation
  786. Texinfo
  787. =======
  788.    If the current directory contains Texinfo source, you must declare it
  789. with the `TEXINFOS' primary.  Generally Texinfo files are converted
  790. into info, and thus the `info_TEXINFOS' macro is most commonly used
  791. here.  Note that any Texinfo source file must end in the `.texi' or
  792. `.texinfo' extension.
  793.    If the `.texi' file `@include's `version.texi', then that file will
  794. be automatically generated.  `version.texi' defines three Texinfo
  795. macros you can reference: `EDITION', `VERSION', and `UPDATED'.  The
  796. first two hold the version number of your package (but are kept
  797. separate for clarity); the last is the date the primary file was last
  798. modified.  The `version.texi' support requires the `mdate-sh' program;
  799. this program is supplied with Automake.
  800.    Sometimes an info file actually depends on more than one `.texi'
  801. file.  For instance, in the `xdvik' distribution, `kpathsea.texi'
  802. includes the files `install.texi', `copying.texi', and `freedom.texi'.
  803. You can tell Automake about these dependencies using the
  804. `texi_TEXINFOS' variable.  Here is how `xdvik' could do it:
  805.      info_TEXINFOS = kpathsea.texi
  806.      kpathsea_TEXINFOS = install.texi copying.texi freedom.texi
  807.    By default, Automake requires the file `texinfo.tex' to appear in
  808. the same directory as the Texinfo source.  However, if you used
  809. `AC_CONFIG_AUX_DIR' in `configure.in', then `texinfo.tex' is looked for
  810. there.  Automake supplies `texinfo.tex'.
  811.    Automake generates an `install-info' target; some people apparently
  812. use this.  By default, info pages are installed by `make install'.
  813. This can be prevented via the `no-installinfo' option.
  814. File: automake.info,  Node: Man pages,  Prev: Texinfo,  Up: Documentation
  815. Man pages
  816. =========
  817.    A package can also include man pages.  (Though see the GNU standards
  818. on this matter, *Note Man Pages: (standards.info)Man Pages.)  Man pages
  819. are declared using the `MANS' primary.  Generally the `man_MANS' macro
  820. is used.  Man pages are automatically installed in the correct
  821. subdirectory of `mandir', based on the file extension.
  822.    By default, man pages are installed by `make install'.  However,
  823. since the GNU project does not require man pages, many maintainers do
  824. not expend effort to keep the man pages up to date.  In these cases, the
  825. `no-installman' option will prevent the man pages from being installed
  826. by default.  The user can still explicitly install them via `make
  827. install-man'.
  828.    Here is how the documentation is handled in GNU `cpio' (which
  829. includes both Texinfo documentation and man pages):
  830.      info_TEXINFOS = cpio.texi
  831.      man_MANS = cpio.1 mt.1
  832.    Texinfo source, info pages and man pages are all considered to be
  833. source for the purposes of making a distribution.
  834. File: automake.info,  Node: Install,  Next: Clean,  Prev: Documentation,  Up: Top
  835. What Gets Installed
  836. *******************
  837.    Naturally, Automake handles the details of actually installing your
  838. program once it has been built.  All `PROGRAMS', `SCRIPTS',
  839. `LIBRARIES', `LISP', `DATA' and `HEADERS' are automatically installed
  840. in the appropriate places.
  841.    Automake also handles installing any specified info and man pages.
  842.    Automake generates separate `install-data' and `install-exec'
  843. targets, in case the installer is installing on multiple machines which
  844. share directory structure - these targets allow the machine-independent
  845. parts to be installed only once.  The `install' target depends on both
  846. of these targets.
  847.    Automake also generates an `uninstall' target, and an `installdirs'
  848. target.
  849.    It is possible to extend this mechanism by defining an
  850. `install-exec-local' or `install-data-local' target.  If these targets
  851. exist, they will be run at `make install' time.
  852. File: automake.info,  Node: Clean,  Next: Dist,  Prev: Install,  Up: Top
  853. What Gets Cleaned
  854. *****************
  855.    The GNU Makefile Standards specify a number of different clean rules.
  856. Generally the files that can cleaned are determined automatically by
  857. Automake.  Of course, Automake also recognizes some variables that can
  858. be defined to specify additional files to clean.  These variables are
  859. `MOSTLYCLEANFILES', `CLEANFILES', `DISTCLEANFILES', and
  860. `MAINTAINERCLEANFILES'.
  861. File: automake.info,  Node: Dist,  Next: Tests,  Prev: Clean,  Up: Top
  862. What Goes in a Distribution
  863. ***************************
  864.    The `dist' target in the generated `Makefile.in' can be used to
  865. generate a gzip'd `tar' file for distribution.  The tar file is named
  866. based on the PACKAGE and VERSION variables; more precisely it is named
  867. `PACKAGE-VERSION.tar.gz'.
  868.    For the most part, the files to distribute are automatically found by
  869. Automake: all source files are automatically included in a distribution,
  870. as are all `Makefile.am's and `Makefile.in's.  Automake also has a
  871. built-in list of commonly used files which, if present in the current
  872. directory, are automatically included.  This list is printed by
  873. `automake --help'.  Also, files which are read by `configure' (ie, the
  874. source files corresponding to the files specified in the `AC_OUTPUT'
  875. invocation) are automatically distributed.
  876.    Still, sometimes there are files which must be distributed, but which
  877. are not covered in the automatic rules.  These files should be listed in
  878. the `EXTRA_DIST' variable.
  879.    Occasionally it is useful to be able to change the distribution
  880. before it is packaged up.  If the `dist-hook' target exists, it is run
  881. after the distribution directory is filled, but before the actual tar
  882. (or shar) file is created.  One way to use this is for distributing file
  883. in subdirectories for which a new `Makefile.am' is overkill:
  884.      dist-hook:
  885.              mkdir $(distdir)/random
  886.              cp -p random/a1 random/a2 $(distdir)/random
  887.    Automake also generates a `distcheck' target which can be help to
  888. ensure that a given distribution will actually work.  `distcheck' makes
  889. a distribution, and then tries to do a `VPATH' build.
  890. File: automake.info,  Node: Tests,  Next: Options,  Prev: Dist,  Up: Top
  891. Support for test suites
  892. ***********************
  893.    Automake supports a two forms of test suite.
  894.    If the variable `TESTS' is defined, its value is taken to be a list
  895. of programs to run in order to do the testing.  The programs can either
  896. be derived objects or source objects; the generated rule will look both
  897. in SRCDIR and `.'.  The number of failures will be printed at the end
  898. of the run.  The variable `TESTS_ENVIRONMENT' can be used to set
  899. environment variables for the test run; the environment variable
  900. `srcdir' is set in the rule.
  901.    If `dejagnu' appears in `AUTOMAKE_OPTIONS', then the a
  902. `dejagnu'-based test suite is assumed.  The value of the variable
  903. `DEJATOOL' is passed as the `--tool' argument to `runtest'; it defaults
  904. to the name of the package.  The variables `EXPECT', `RUNTEST' and
  905. `RUNTESTFLAGS' can also be overridden to provide project-specific
  906. values.  For instance, you will need to do this if you are testing a
  907. compiler toolchain, because the default values do not take into account
  908. host and target names.
  909.    In either case, the testing is done via `make check'.
  910. File: automake.info,  Node: Options,  Next: Miscellaneous,  Prev: Tests,  Up: Top
  911. Changing Automake's Behavior
  912. ****************************
  913.    Various features of Automake can be controlled by options in the
  914. `Makefile.am'.  Such options are listed in a special variable named
  915. `AUTOMAKE_OPTIONS'.  Currently understood options are:
  916. `gnits'
  917. `gnu'
  918. `foreign'
  919.      The same as the corresponding `--strictness' option.
  920. `no-installman'
  921.      The generated `Makefile.in' will not cause man pages to be
  922.      installed by default.  However, an `install-man' target will still
  923.      be available for optional installation.  This option is disallowed
  924.      at `GNU' strictness and above.
  925. `no-installinfo'
  926.      The generated `Makefile.in' will not cause info pages to be built
  927.      or installed by default.  However, `info' and `install-info'
  928.      targets will still be available.  This option is disallowed at
  929.      `GNU' strictness and above.
  930. `ansi2knr'
  931. `path/ansi2knr'
  932.      Turn on automatic de-ANSI-fication.  *Note ANSI::.  If preceeded
  933.      by a path, the generated `Makefile.in' will look in the specified
  934.      directory to find the `ansi2knr' program.  Generally the path
  935.      should be a relative path to another directory in the same
  936.      distribution (though Automake currently does not check this).  It
  937.      is up to you to make sure that the specified directory is built
  938.      before the current directory; if `ansi2knr' does not exist then
  939.      the build will fail.
  940. `dejagnu'
  941.      Cause `dejagnu'-specific rules to be generated.  *Note Tests::.
  942. `dist-shar'
  943.      Generate a `dist-shar' target as well as the ordinary `dist'
  944.      target.  This new target will create a shar archive of the
  945.      distribution.
  946. `dist-zip'
  947.      Generate a `dist-zip' target as well as the ordinary `dist'
  948.      target.  This new target will create a zip archive of the
  949.      distribution.
  950. `dist-tarZ'
  951.      Generate a `dist-tarZ' target as well as the ordinary `dist'
  952.      target.  This new target will create a compressed tar archive of
  953.      the distribution; a traditional `tar' and `compress' will be
  954.      assumed.  Warning: if you are actually using `GNU tar', then the
  955.      generated archive might contain nonportable constructs.
  956. `no-dependencies'
  957.      This is similar to using `--include-deps' on the command line, but
  958.      is useful for those situations where you don't have the necessary
  959.      bits to make automatic dependency tracking work *Note
  960.      Dependencies::.  In this case the effect is to effectively disable
  961.      automatic dependency tracking.
  962. VERSION
  963.      A version number (eg `0.30') can be specified.  If Automake is not
  964.      newer than the version specified, creation of the `Makefile.in'
  965.      will be suppressed.
  966.    Unrecognized options are diagnosed by `automake'.
  967.