+ - Fixed a gross inefficiency in the recipes for installing byte-compiled
+ python files, that was causing an O(N^2) performance on the number N of
+ files, instead of the expected O(N) performance. Note that this bug
+ was only relevant when the number of python files was high (which is
+ unusual in practice).
+
+ - Automake try to offer a more reproducible output for warning messages,
+ in the face of the newly-introduced randomization for hash keys order
+ in Perl 5.18.
+
+ - The 'test-driver' script now actually error out with a clear error
+ message on the most common invalid usages.
+
+ - Several spurious failures/hangs in the testsuite (bugs #14706, #14707,
+ #14760, #14911, #15181, #15237).
+
+* Documentation fixes:
+
+ - Fixed typos in the 'fix-timestamp.sh' example script that made it
+ nonsensical.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+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 is
+ dynamically computed only at configure runtime (really!) 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: