+ (defined in '/usr/local/share/aclocal-2.0/vala.m4').
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.14:
+
+* C compilation, and the AC_PROG_CC and AM_PROG_CC_C_O macros:
+
+ - The 'compile' script is now unconditionally required for all packages
+ that perform C compilation (if you are using the '--add-missing'
+ option, automake will fetch that script for you, so you shouldn't
+ need any explicit adjustment). This new behaviour is needed to avoid
+ obscure errors when the 'subdir-objects' option is used, and the
+ compiler is an inferior one that doesn't grasp the combined use of
+ both the "-c -o" options; see discussion about automake bug#13378 for
+ more details:
+ <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#35>
+ <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#44>
+
+ - The next major Automake version (2.0) will unconditionally activate
+ the 'subdir-objects' option. In order to smooth out the transition,
+ we now give a warning (in the category 'unsupported') whenever a
+ source file is present in a subdirectory but the 'subdir-object' is
+ not enabled. For example, the following usage will trigger such a
+ warning:
+
+ bin_PROGRAMS = sub/foo
+ sub_foo_SOURCES = sub/main.c sub/bar.c
+
+ - Automake will automatically enhance the autoconf-provided macro
+ AC_PROG_CC to force it to check, at configure time, that the
+ C compiler supports the combined use of both the '-c' and '-o'
+ options. The result of this check is saved in the cache variable
+ 'am_cv_prog_cc_c_o', and said result can be overridden by
+ pre-defining that variable.
+
+ - The AM_PROG_CC_C_O macro can still be called, albeit that should no
+ longer be necessary. This macro is now just a thin wrapper around the
+ Automake-enhanced AC_PROG_CC. This means, among the other things,
+ that its behaviour is changed in three ways:
+
+ 1. It no longer invokes the Autoconf-provided AC_PROG_CC_C_O
+ macro behind the scenes.
+
+ 2. It caches the check result in the 'am_cv_prog_cc_c_o' variable,
+ and not in a 'ac_cv_prog_cc_*_c_o' variable whose exact name
+ in only dynamically computed *at configure runtime* from the
+ content of the '$CC' variable.
+
+ 3. It no longer automatically AC_DEFINE the C preprocessor
+ symbol 'NO_MINUS_C_MINUS_O'.
+
+* Texinfo support:
+
+ - Automake can now be instructed to place '.info' files generated from
+ Texinfo input in the builddir rather than in the srcdir; this is done
+ specifying the new automake option 'info-in-builddir'. This feature
+ was requested by the developers of GCC, GDB, GNU binutils and the GNU
+ bfd library. See the extensive discussion about automake bug#11034
+ for more details.
+
+ - For quite a long time, Automake has been implementing an undocumented
+ hack which ensured that '.info' files which appeared to be cleaned
+ (by being listed in the CLEANFILES or DISTCLEANFILES variables) were
+ built in the builddir rather than in the srcdir; this hack was
+ introduced to ensure better backward-compatibility with package
+ such as Texinfo, which do things like:
+
+ info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
+ DISTCLEANFILES = texinfo texinfo-* info*.info*
+ # Do not create info files for distribution.
+ dist-info:
+ @:
+
+ in order not to distribute generated '.info' files.
+
+ Now that we have the 'info-in-builddir' option that explicitly causes
+ generated '.info' files to be placed in the builddir, this hack should
+ be longer necessary, so we deprecate it with runtime warnings. It will
+ likely be removed altogether in Automake 2.0.
+
+* Relative directory in Makefile fragments:
+
+ - The special Automake-time substitutions '%reldir%' and '%canon_reldir%'
+ (and their short versions, '%D%' and '%C%' respectively) can now be used
+ in an included Makefile fragment. The former is substituted with the
+ relative directory of the included fragment (compared to the top-level
+ including Makefile), and the latter with the canonicalized version of
+ the same relative directory.
+
+ # in 'Makefile.am':
+ bin_PROGRAMS = # will be updated by included Makefile fragments
+ include src/Makefile.inc
+
+ # in 'src/Makefile.inc':
+ bin_PROGRAMS += %reldir%/foo
+ %canon_reldir%_foo_SOURCES = %reldir%/bar.c
+
+ This should be especially useful for packages using a non-recursive
+ build system.
+
+* Deprecated distribution formats:
+
+ - The 'shar' and 'compress' distribution formats are deprecated, and
+ scheduled for removal in Automake 2.0. Accordingly, the use of the
+ 'dist-shar' and 'dist-tarZ' will cause warnings at automake runtime
+ (in the 'obsolete' category), and the recipes of the Automake-generated
+ targets 'dist-shar' and 'dist-tarZ' will unconditionally display
+ (non-fatal) warnings at make runtime.
+
+* New configure runtime warnings about "rm -f" support:
+
+ - To simplify transition to Automake 2.0, the shell code expanded by
+ AM_INIT_AUTOMAKE now checks (at configure runtime) that the default
+ 'rm' program in PATH doesn't complain when called without any
+ non-option argument if the '-f' option is given (so that commands like
+ "rm -f" and "rm -rf" act as a no-op, instead of raising usage errors).
+ If this is not the case, the configure script is aborted, to call the
+ attention of the user on the issue, and invite him to fix his PATH.
+ The checked 'rm' behavior is very widespread in the wild, and will be
+ required by future POSIX versions:
+
+ <http://austingroupbugs.net/view.php?id=542>
+
+ The user can still force the configure process to complete even in the
+ presence of a broken 'rm' by defining the ACCEPT_INFERIOR_RM_PROGRAM
+ environment variable to "yes". And the generated Makefiles should
+ still work correctly even when such broken 'rm' is used. But note
+ that this will no longer be the case with Automake 2.0 though, so, if
+ you encounter the warning, please report it to us ASAP (and try to fix
+ your environment as well).
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13.4:
+
+* Bugs fixed:
+
+ - Fix a minor regression introduced in Automake 1.13.3: when two or more
+ user-defined suffix rules were present in a single Makefile.am,
+ automake would needlessly include definition of some make variables
+ related to C compilation in the generated Makefile.in (bug#14560).
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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.
+
+ - If the same user-defined suffixes were transformed into different
+ Automake-known suffixes in different Makefile.am files in the same
+ project, automake could get confused and 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 placed 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. Remove brittleness due to the use of "make -e" in test cases.
+
+ 2. Seamlessly allow 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).
+
+ - Several spurious failures have been fixed (they hit especially
+ MinGW/MSYS builds). See automake bugs #14493, #14494, #14495,
+ #14498, #14499, #14500, #14501, #14517 and #14528.
+
+ - Some other minor miscellaneous changes and fixlets.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.13.2:
+
+* 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.
+
+* 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. Simply
+ use the '.info' extension for all your info files, transforming
+ usages like:
+
+ @setfilename myprogram
+
+ into:
+
+ @setfilename myprogram.info
+
+ - 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.
+
+* 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: