+ (defined in '/usr/local/share/aclocal-2.0/vala.m4').
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13.3:
+
+* Documentation fixes:
+
+ - The documentation no longer mistakenly reports that the obsolete
+ 'AM_MKDIR_PROG_P' macro and '$(mkdir_p)' make variable are going
+ to be removed in Automake 2.0.
+
+* Bugs fixed:
+
+ - Byte-compilation of Emacs lisp files could fail spuriously on Solaris,
+ when /bin/ksh or /usr/xpg4/bin/sh were used as shell.
+
+ - The same user-defined suffix being transformed into different
+ Automake-known suffixes in different Makefiles could confuse automake
+ and make it generate inconsistent Makefiles (automake bug#14441).
+ For example, if 'Makefile.am' contained a ".ext.cc:" suffix rule, and
+ 'sub/Makefile.am' contained a ".ext.c:" suffix rule, automake would
+ have mistakenly put into 'Makefile.in' rules to compile *.c files
+ into object files, and into 'sub/Makefile.in' rules to compile *.cc
+ files into object files --- rather than the other way around.
+ This is now fixed.
+
+* Testsuite work:
+
+ - The test cases no longer have the executable bit set. This should
+ make it clear that they are not meant to be run directly; as
+ explained in t/README, they can only be run through the custom
+ 'runtest' script, or by a "make check" invocation.
+
+ - The testsuite has seen the introduction of a new helper function
+ 'run_make', and several related changes. These serve a two-fold
+ purpose:
+
+ 1. Removing brittleness due to the use of "make -e" in test cases.
+
+ 2. Seamlessly allowing the use of parallel make ("make -j...") in
+ the test cases, even where redirection of make output is involved
+ (see automake bug#11413 for a description of the subtle issues in
+ this area).
+
+ - Few spurious failures have been fixed (they hit especially MinGW/MSYS).
+ See automake bugs #14493, #14494, #14495, #14498, #14499, #14500 and
+ #14501.
+
+ - Some other minor miscellaneous changes and fixlets.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13.2:
+
+* Obsolescent features:
+
+ - Use of suffix-less info files (that can be specified through the
+ '@setfilename' macro in Texinfo input files) is discouraged, and
+ its use will raise warnings in the 'obsolete' category.
+
+ - Use of Texinfo input files with '.txi' or '.texinfo' extensions
+ is discouraged, and its use will raise warnings in the 'obsolete'
+ category. You are advised to simply use the '.texi' extension
+ instead.
+
+* Documentation fixes:
+
+ - The long-deprecated but still supported two-arguments invocation form
+ of AM_INIT_AUTOMAKE is documented once again. This seems the sanest
+ thing to do, given that support for such usage might need to remain
+ in place for an unspecified amount of time in order to cater to people
+ who want to define the version number for their package dynamically at
+ configure runtime (unfortunately, Autoconf does not yet support this
+ scenario, so we cannot delegate the work to it).
+
+ - The serial testsuite harness is no longer reported as "deprecated",
+ but as "discouraged". We have no plan to remove it, nor to make its
+ use cause runtime warnings.
+
+ - The parallel testsuite is no longer reported as "experimental"; it
+ is well tested, and should be stable now.
+
+ - The 'shar' and 'tarZ' distribution formats and the 'dist-shar' and
+ 'dist-tarZ' options are obsolescent, and their use is deprecated
+ in the documentation.
+
+ - Other minor miscellaneous fixes and improvements; in particular,
+ some improvements in cross-references.
+
+* Bugs fixed:
+
+ - When the 'ustar' option is used, the generated configure script no
+ longer risks hanging during the tests for the availability of the
+ 'pax' utility, even if the user running configure has a UID or GID
+ that requires more than 21 bits to be represented.
+ See automake bug#8343 and bug#13588.
+
+ - The obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC work once
+ again, as they did in Automake 1.12.x (albeit printing runtime
+ warnings in the 'obsolete' category). Removing them has turned
+ out to be a very bad idea, because it complicated distro packing
+ enormously. Making them issue fatal warnings, as we did in
+ Automake 1.13, has turned out to be a similarly very bad idea,
+ for exactly the same reason.
+
+ - aclocal will no longer error out if the first local m4 directory
+ (as specified by the '-I' option or the 'AC_CONFIG_MACRO_DIRS' or
+ 'AC_CONFIG_MACRO_DIR' macros) doesn't exist; it will merely report
+ a warning in the 'unsupported' category. This is done to support
+ some pre-existing real-world usages. See automake bug#13514.
+
+ - aclocal will no longer consider directories for extra m4 files more
+ than once, even if they are specified multiple times. This ensures
+ packages that specify both
+
+ AC_CONFIG_MACRO_DIR([m4]) in configure.ac
+ ACLOCAL_AMFLAGS = -I m4 in Makefile.am
+
+ will work correctly, even when the 'm4' directory contains no
+ package-specific files, but is used only to install third-party
+ m4 files (as can happen with e.g., "libtoolize --install").
+ See automake bug#13514.
+
+ - Analysis of make flags in Automake-generated rules has been made more
+ robust, and more future-proof. For example, in presence of make that
+ (like '-I') take an argument, the characters in said argument will no
+ longer be spuriously considered as a set of additional make options.
+ In particular, automake-generated rules will no longer spuriously
+ believe to be running in dry mode ("make -n") if run with an invocation
+ like "make -I noob"; nor will they believe to be running in keep-going
+ mode ("make -k") if run with an invocation like "make -I kool"
+ (automake bug#12554).
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13.1:
+
+* Bugs fixed:
+
+ - Use of the obsolete macros AM_CONFIG_HEADER or AM_PROG_CC_STDC now
+ causes a clear and helpful error message, instead of obscure ones
+ (issue introduced in Automake 1.13).
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13:
+
+* Bugs fixed:
+
+ - ylwrap renames properly header guards in generated header files
+ (*.h), instead of leaving Y_TAB_H.
+
+ - ylwrap now also converts header guards in implementation files
+ (*.c). Because ylwrap failed to rename properly #include in the
+ implementation files, current versions of Bison (e.g., 2.7)
+ duplicate the generated header file in the implementation file.
+ The header guard then protects the implementation file from
+ duplicate definitions from the header file.