tests: avoid a spurious failure on MSYS
[platform/upstream/automake.git] / NEWS
diff --git a/NEWS b/NEWS
index f308752..39f5121 100644 (file)
--- a/NEWS
+++ b/NEWS
+* WARNING: New versioning scheme for Automake.
+
+  - Starting with this version onward, Automake will use an update and
+    more rational versioning scheme, one that will allow users to know
+    which kind of changes can be expected from a new version, based on
+    its version number.
+
+    + Micro versions (e.g., 1.13.3, 2.0.1, 3.2.8) will introduce only
+      documentation updates and bug and regression fixes; they will
+      not introduce new features, nor any backward-incompatibility (any
+      such incompatibility would be considered a bug, to be fixed with
+      a further micro release).
+
+    + Minor versions (e.g., 1.14, 2.1) can introduce new backward
+      compatible features; the only backward-incompatibilities allowed
+      in such a release are new *non-fatal* deprecations and warnings,
+      and possibly fixes for old or non-trivial bugs (or even inefficient
+      behaviours) that could unfortunately have been seen, and used, by
+      some developers as "corner case features".  Possible disruptions
+      caused by this kind of fixes should hopefully be quite rare.
+
+    + Major versions (now expected to be released every 18 or 24 months,
+      and not more often) can introduce new big features (possibly with
+      rough edges and not-fully-stabilized APIs), removal of deprecated
+      features, backward-incompatible changes of behaviour, and possibly
+      major refactorings (that, while ideally transparent to the user,
+      could introduce new bugs).  Incompatibilities should however not
+      be introduced gratuitously and abruptly; a proper deprecation path
+      should be duly implemented in the preceding minor releases.
+
+  - According to this new scheme, the next major version of Automake
+    (the one that has until now been labelled as '1.14') will actually
+    become "Automake 2.0".  Automake 1.14 will be the next minor version,
+    which will introduce new features, deprecations and bug fixes, but
+    no real backward incompatibility.
+
+  - See discussion about automake bug#13578 for more details and
+    background: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13578>
+
+* WARNING: Future backward-incompatibilities!
+
+  - Makefile recipes generated by Automake 2.0 will expect to use an
+    'rm' program that 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" will act as a no-op, instead of raising usage errors).
+    Accordingly, AM_INIT_AUTOMAKE will expand new shell code checking
+    that the default 'rm' program in PATH satisfies this requirement, and
+    aborting the configure process if this is not the case.  This behavior
+    of 'rm' is very widespread in the wild, and it will be required in the
+    next POSIX version:
+    <http://austingroupbugs.net/view.php?id=542>
+
+  - Automake 2.0 will require Autoconf 2.70 or later (which is still
+    unreleased at the moment of writing, but is planned to be released
+    before Automake 2.0 is).
+
+  - Automake 2.0 will drop support for the long-deprecated 'configure.in'
+    name for the Autoconf input file.  You are advised to start using the
+    recommended name 'configure.ac' instead, ASAP.
+
+  - The ACLOCAL_AMFLAGS special make variable will be fully deprecated
+    in Automake 2.0 (where it will raise warnings in the "obsolete"
+    category).  You are advised to start relying on the new Automake
+    support for AC_CONFIG_MACRO_DIRS instead (which was introduced in
+    Automake 1.13).
+
+  - Automake 2.0 will remove support for automatic dependency tracking
+    with the SGI C/C++ compilers on IRIX.  The SGI depmode has been
+    reported broken "in the wild" already, and we don't think investing
+    time in debugging and fixing is worthwhile, especially considering
+    that SGI has last updated those compilers in 2006, and is expected
+    to retire support for them in December 2013:
+    <http://www.sgi.com/services/support/irix_mips_support.html>
+
+  - Future versions of Automake might remove support for MS-DOS and
+    Windows 95/98/ME (support for them was offered by relying on the
+    DJGPP project).  Note however that both Cygwin and MSYS/MinGW on
+    modern Windows versions will continue to be fully supported.
+
+  - Automake-provided scripts and makefile recipes might (finally!)
+    start assuming a POSIX shell in Automake 2.0.
+
+  - Starting from Automake 2.0, third-party m4 files located in the
+    system-wide aclocal directory, as well as in any directory listed
+    in the ACLOCAL_PATH environment variable, will take precedence
+    over "built-in" Automake macros.  For example (assuming Automake
+    is installed in the /usr/local hierarchy), a definition of the
+    AM_PROG_VALAC macro found in '/usr/local/share/aclocal/my-vala.m4'
+    should take precedence over the same-named automake-provided macro
+    (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).
+
+   - 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.
+
 * Version requirements:
 
-  - Autoconf 2.65 or greater is required.
+  - Autoconf 2.65 or greater is now required.
 
   - The rules to build PDF and DVI output from Texinfo input now
-    requires Texinfo 4.9 or later.
-
-* Obsolete features removed:
+    require Texinfo 4.9 or later.
 
-  - Use of the long-deprecated two- and three-arguments invocation forms
-    of the AM_INIT_AUTOMAKE is not supported anymore.
+* Obsolete features:
 
   - Support for the "Cygnus-style" trees (once enabled by the 'cygnus'
     option) has been removed.  See discussion about automake bug#11034
-    for more background.
-
-  - The automake-provided '@mkdir_p@' configure substitution and
-    AM_PROG_MKDIR m4 macro have been removed.  They had been obsolete
-    since automake 1.10, and actively deprecated since Automake 1.12.1.
-    However, to maintain a degree of backward-compatibility, the make
-    variable '$(mkdir_p)' is still defined (now simple as an alias to
-    '$(MKDIR_P)').  It will probably be removed in future major versions
-    of Automake (probably 1.14).
+    for more background: <http://debbugs.gnu.org/11034>.
 
   - The deprecated aclocal option '--acdir' has been removed.  You
     should use the options '--automake-acdir' and '--system-acdir'
@@ -44,6 +276,38 @@ New in 1.13:
 
   - All the "old alias" macros in 'm4/obsolete.m4' have been removed.
 
+  - Use of the long-deprecated two- and three-arguments invocation forms
+    of the AM_INIT_AUTOMAKE is no longer documented.  It's still supported
+    though (albeit with a warning in the 'obsolete' category), to cater
+    for people who want to define the version number for their package
+    dynamically (e.g., from the current VCS revision).  We'll have to
+    continue this support until Autoconf itself is fixed to allow better
+    support for such dynamic version numbers.
+
+* Elisp byte-compilation:
+
+  - The byte compilation of '.el' files into '.elc' files is now done
+    with a suffix rule.  This has simplified the compilation process, and
+    more importantly made it less brittle.  The downside is that emacs is
+    now invoked once for each '.el' files, which cause some noticeable
+    slowdowns.  These should however be mitigated on multicore machines
+    (which are becoming the norm today) if concurrent  make ("make -j")
+    is used.
+
+  - Elisp files placed in a subdirectory are now byte-compiled to '.elc'
+    files in the same subdirectory; for example, byte-compiling of file
+    'sub/foo.el' file will result in 'sub/foo.elc' rather than in
+    'foo.elc'.  This behaviour is backward-incompatible with older
+    Automake versions, but it is more natural and more sane.  See also
+    automake bug#7441.
+
+  - The Emacs invocation performing byte-compilation of '.el' files honors
+    the $(AM_ELCFLAGS) and $(ELCFLAGS) variables; as typical, the former
+    one is  developer-reserved and the latter one user-reserved.
+
+  - The 'elisp-comp' script, once provided by Automake, has been rendered
+    obsoleted by the just-described changes, and thus removed.
+
 * Changes to Automake-generated testsuite harnesses:
 
   - The parallel testsuite harness (previously only enabled by the
@@ -66,11 +330,14 @@ New in 1.13:
     "make V=0" to enable quieter output in the package he's building.
 
   - The 'silent-rules' option has now become a no-op, preserved for
-    backward-compatibility only.  In particular, its use does not disable
-    the warnings in the 'portability-recursive' category anymore.
+    backward-compatibility only.  In particular, its use no longer
+    disables the warnings in the 'portability-recursive' category.
 
 * Texinfo Support:
 
+  - The rules to build PDF and DVI files from Texinfo input now require
+    Texinfo 4.9 or later.
+
   - The rules to build PDF and DVI files from Texinfo input now use the
     '--build-dir' option, to keep the auxiliary files used by texi2dvi
     and texi2pdf around without cluttering the build directory, and to
@@ -78,11 +345,11 @@ New in 1.13:
 
 * Automatic remake rules and 'missing' script:
 
-  - The 'missing' script does not try anymore to update the timestamp
-    of out-of-date files that require a maintainer-specific tool to be
+  - The 'missing' script no longer tries to update the timestamp of
+    out-of-date files that require a maintainer-specific tool to be
     remade, in case the user lacks such a tool (or has a too-old version
-    of it).  It just give a useful warning, and in some cases also a tip
-    about how to obtain such a tool.
+    of it).  It just gives a useful warning, and in some cases also a
+    tip about how to obtain such a tool.
 
   - The missing script has thus become useless as a (poor) way to work
     around the sketched-timestamps issues that can happen for projects
@@ -98,66 +365,157 @@ New in 1.13:
     specifying the name of such targets in invocations of the new
     'AM_EXTRA_RECURSIVE_TARGETS' m4 macro.
 
+* Tags:
+
   - Any failure in the recipe of the "tags", "ctags", "cscope" or
     "cscopelist" targets in a subdirectory is now propagated to the
     top-level make invocation.
 
+  - Tags are correctly computed also for files in _SOURCES variables that
+    only list files with non-standard suffixes (see automake bug#12372).
+
 * Improvements to aclocal and related rebuilds rules:
 
-  - The Autoconf-provided macro AC_CONFIG_MACRO_DIR is now traced by
-    aclocal, and can be used to declare the local m4 include directory.
-    Formerly, one had to specify it with an explicit '-I' option to the
-    'aclocal' invocation.
+  - Autoconf-provided macros AC_CONFIG_MACRO_DIR and AC_CONFIG_MACRO_DIRS
+    are now traced by aclocal, and can be used to declare the local m4
+    include directories.  Formerly, one had to specify it with an explicit
+    '-I' option to the 'aclocal' invocation.
 
   - The special make variable ACLOCAL_AMFLAGS is deprecated; future
     Automake versions will warn about its use, and later version will
     remove support for it altogether.
 
+* The depcomp script:
+
+  - Dropped support for libtool 1.4.
+
+  - Various internal refactorings.  They should cause no visible change,
+    but the chance for regression is there anyway, so please report any
+    unexpected or suspicious behaviour.
+
+  - Support for pre-8.0 versions of the Intel C Compiler has been dropped.
+    This should cause no problem, since icc 8.0 has been released in
+    December 2003 -- almost nine years ago.
+
+  - Support for tcc (the Tiny C Compiler) has been improved, and is now
+    handled through a dedicated 'tcc' mode.
+
+* The ylwrap script:
+
+  - ylwrap generates header guards with a single '_' for series of non
+    alphabetic characters, instead of several.  This is what Bison >=
+    2.5.1 does.
+
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-New in 1.12.3:
+Bugs fixed in 1.12.6:
 
-* WARNING: Future backward-incompatibilities!
+* Python-related bugs:
 
-  - Future versions of Automake will likely drop support for the
-    long-deprecated 'configure.in' name for the Autoconf input file.
-    You are advised to use the recommended name 'configure.ac' instead.
+  - The default installation location for python modules has been improved
+    for Python 3 on Debian and Ubuntu systems, changing from:
 
-  - Starting from the next major Automake version (1.13), the rules to
-    build pdf, ps and dvi output from Texinfo input will use the '--tidy'
-    option by default.  Since such an option was introduced in Texinfo
-    4.9, this means that Makefiles generated by future Automake versions
-    will require at least that version of Texinfo.
+        ${prefix}/lib/python3/dist-packages
 
-  - Starting from the next major Automake version (1.13), the parallel
-    testsuite harness (previously only enabled by the 'parallel-tests'
-    option) will become the default one; the older serial testsuite
-    harness will still be available through the use of the 'serial-tests'
-    option.
+    to
 
-  - Support for the two- and three-arguments invocation forms of the
-    AM_INIT_AUTOMAKE macro is deprecated, and will be removed in the
-    next major Automake version (1.13).
+        ${prefix}/lib/python3.x/site-packages
 
-  - The exact order in which the directories in the aclocal macro
-    search path are looked up is probably going to be changed in the
-    next Automake release (1.13).
+    This change should ensure modules installed using the default ${prefix}
+    "/usr/local" are found by default by system python 3.x installations.
+    See automake bug#10227.
 
-  - The 'missing' script will not try anymore to update the timestamp
-    of out-of-date files that require a maintainer-specific tool to be
-    remade, in case the user lacks such a tool (or has a too-old version
-    of it).  In fact, starting from Automake 1.13, all it'll do will be
-    giving more useful warnings than a bare "command not found" from a
-    make recipe would.
+  - Python byte-compilation supports the new layout mandated by PEP-3147,
+    with its __pycache__ directory (automake bug#8847).
+
+* Build system issues:
+
+  - The maintainer rebuild rules for Makefiles and aclocal.m4 in
+    Automake's own build system works correctly again (bug introduced
+    in Automake 1.12.5).
+
+* Testsuite issues:
+
+  - The Vala-related tests has been changed to adjust to the removal of
+    the 'posix' profile in the valac compiler.  See automake bug#12934
+    a.k.a. bug#12522.
+
+  - Some spurious testsuite failures related to older tools and systems
+    have been fixed.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.12.5:
+
+* Vala support:
+
+  - The AM_PROG_VALAC macro has been enhanced to takes two further
+    optional arguments; it's signature now being
+
+        AM_PROG_VALAC([MINIMUM-VERSION], [ACTION-IF-FOUND],
+                      [ACTION-IF-NOT-FOUND])
+
+  - By default, AM_PROG_VALAC no longer aborts the configure invocation
+    if the Vala compiler found is too old, but simply prints a warning
+    messages (as it did when the Vala compiler was not found).  This
+    should avoid unnecessary difficulties for end users that just want
+    to compile the unmodified, distributed Vala-generated C sources,
+    but happens to have an old Vala compiler in their PATH.  This fixes
+    automake bug#12688.
+
+  - If no proper Vala compiler is found at configure runtime, AM_PROG_VALAC
+    will set the AC_SUBST'd variable 'VALAC' to 'valac' rather than to ':'.
+    This is a better default, because with it a triggered makefile rule
+    invoking a Vala compilation will clearly fail with an informative error
+    message like "valac: command not found", rather than silently, with
+    the error possibly going unnoticed or triggering harder-to-diagnose
+    fallout failures in later steps.
 
 * Miscellaneous changes:
 
-  - The '.m4' files provided by Automake does not define serial numbers
-    anymore.  This should cause no difference in the behaviour of aclocal
-    though.
+  - automake and aclocal no longer honours the 'perllibdir' environment
+    variable.  That had always been intended only as an hack required in
+    the testsuite, not meant for any use beyond that.
+
+Bugs fixed in 1.12.5:
+
+* Long-standing bugs:
+
+  - Automake no longer generates spurious remake rules invoking autoheader
+    to regenerate the template corresponding to header files specified after
+    the first one in AC_CONFIG_HEADERS (automake bug#12495).
+
+  - When wrapping Microsoft tools, the 'compile' script falls back to
+    finding classic 'libname.a' style libraries when 'name.lib' and
+    'name.dll.lib' aren't available.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.12.4:
+
+* Warnings and deprecations:
+
+  - Warnings in the 'obsolete' category are enabled by default both in
+    automake and aclocal.
+
+* Miscellaneous changes:
 
   - Some testsuite weaknesses and spurious failures have been fixed.
 
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New in 1.12.3:
+
+* Miscellaneous changes:
+
+  - The '.m4' files provided by Automake no longer define serial numbers.
+    This should cause no difference in the behaviour of aclocal though.
+
+  - Some testsuite weaknesses and spurious failures have been fixed.
+
+  - There is initial support for automatic dependency tracking with the
+    Portland Group C/C++ compilers, thanks to the new new depmode 'pgcc'.
+
 Bugs fixed in 1.12.3:
 
 * Long-standing bugs:
@@ -243,8 +601,8 @@ New in 1.12.1:
 
   - Use of the long-deprecated two- and three-arguments invocation forms
     of the AM_INIT_AUTOMAKE macro now elicits a warning in the 'obsolete'
-    category.  Starting from the next major Automake release (1.13), such
-    usages won't be allowed anymore.
+    category.  Starting from some future major Automake release (likely
+    post-1.13), such usages will no longer be allowed.
 
   - Support for the "Cygnus-style" trees (enabled by the 'cygnus' option) is
     now deprecated (its use triggers a warning in the 'obsolete' category).
@@ -258,13 +616,12 @@ New in 1.12.1:
 * Miscellaneous changes:
 
   - The Automake test cases now require a proper POSIX-conforming shell.
-    Older non-POSIX Bourne shells (like Solaris 10 /bin/sh) won't be
-    accepted anymore.  In most cases, the user shouldn't have to specify
-    such POSIX shell explicitly, since it will be looked up at configure
-    time.  Still, when this lookup fails, or when the user wants to
-    override its conclusion, the variable 'AM_TEST_RUNNER_SHELL' can be
-    used (pointing to the shell that will be used to run the Automake
-    test cases).
+    Older non-POSIX Bourne shells (like Solaris 10 /bin/sh) will no longer
+    be accepted.  In most cases, the user shouldn't have to specify such
+    POSIX shell explicitly, since it will be looked up at configure time.
+    Still, when this lookup fails, or when the user wants to override its
+    conclusion, the variable 'AM_TEST_RUNNER_SHELL' can be used (pointing
+    to the shell that will be used to run the Automake test cases).
 
 Bugs fixed in 1.12.1:
 
@@ -370,7 +727,7 @@ New in 1.12:
     the '--add-missing' option, or manually copy the 'test-driver' script
     into their tree.  The second, and more important, implication is that
     now, when the 'parallel-tests' option is in use, TESTS_ENVIRONMENT can
-    not be used anymore to define a test runner, and the command specified
+    no longer be used to define a test runner, and the command specified
     in LOG_COMPILER (and <ext>_LOG_COMPILER) must be a *real* executable
     program or script.  For example, this is still a valid usage (albeit
     a little contorted):
@@ -383,7 +740,7 @@ New in 1.12:
         fi;
       LOG_COMPILER = $(SHELL) $$maybe_errexit
 
-    while this is not anymore:
+    OTOH, this is no longer a valid usage:
 
       TESTS_ENVIRONMENT = \
         $(SHELL) `test -n '$(STRICT_TESTS_CHECKING)' && echo ' -e'`
@@ -484,9 +841,9 @@ Bugs fixed in 1.12:
   - The AM_COND_IF macro also works if the shell expression for the
     conditional is no longer valid for the condition.
 
-  - The automake-provided parallel testsuite harness does not fail anymore
-    with BSD make used in parallel mode when there are test scripts in a
-    subdirectory, like in:
+  - The automake-provided parallel testsuite harness no longer fails
+    with BSD make used in parallel mode when there are test scripts in
+    subdirectory, like in:
 
       TESTS = sub/foo.test sub/bar.test
 
@@ -561,7 +918,7 @@ Bugs fixed in 1.11.4:
 * Bugs introduced by 1.11.2:
 
   - A definition of 'noinst_PYTHON' before 'python_PYTHON' (or similar)
-    don't cause spurious failures upon "make install" anymore.
+    no longer cause spurious failures upon "make install".
 
   - The user can now instruct the 'uninstall-info' rule not to update
     the '${infodir}/dir' file by exporting the environment variable
@@ -579,9 +936,9 @@ Bugs fixed in 1.11.4:
     '-I' is non-existent, aclocal will now create it before trying to copy
     files in it.
 
-  - An empty declaration of a "foo_PRIMARY" don't cause anymore the
-    generated install rules to create an empty $(foodir) directory;
-    for example, if Makefile.am contains something like:
+  - An empty declaration of a "foo_PRIMARY" no longer cause the generated
+    install rules to create an empty $(foodir) directory; for example, if
+    Makefile.am contains something like:
 
       pkglibexec_SCRIPTS =
       if FALSE
@@ -599,15 +956,15 @@ New in 1.11.3:
   - Automake's own build system is more silent by default, making use of
     the 'silent-rules' option.
 
-  - The master copy of the `gnupload' script is now maintained in gnulib,
+  - The master copy of the 'gnupload' script is now maintained in gnulib,
     not in automake.
 
-  - The `missing' script doesn't try to wrap calls to `tar' anymore.
+  - The 'missing' script no longer tries to wrap calls to 'tar'.
 
-  - "make dist" doesn't wrap `tar' invocations with the `missing' script
-    anymore.  Similarly, the obsolescent variable `$(AMTAR)' (which you
-    shouldn't be using BTW ;-) does not invoke the missing script anymore
-    to wrap tar, but simply invokes the `tar' program itself.
+  - "make dist" no longer wraps 'tar' invocations with the 'missing'
+    script.  Similarly, the obsolescent variable '$(AMTAR)' (which you
+    shouldn't be using BTW ;-) no longer invokes the 'missing' script
+    to wrap tar, but simply invokes the 'tar' program itself.
 
   - "make dist" can now create lzip-compressed tarballs.
 
@@ -633,24 +990,24 @@ Bugs fixed in 1.11.3:
 * Bugs introduced by 1.11.2:
 
   - Automake now correctly recognizes the prefix/primary combination
-   `pkglibexec_SCRIPTS' as valid.
+   'pkglibexec_SCRIPTS' as valid.
 
-  - The parallel-tests harness doesn't trip anymore on sed implementations
+  - The parallel-tests harness no longer trips on sed implementations
     with stricter limits on the length of input lines (problem seen at
     least on Solaris 8).
 
 * Long-standing bugs:
 
   - The "deleted header file problem" for *.am files is avoided by stub
-    rules.  This allows `make' to trigger a rerun of `automake' also if
-    some previously needed `.am' file has been removed.
+    rules.  This allows 'make' to trigger a rerun of 'automake' also if
+    some previously needed '.am' file has been removed.
 
-  - The `silent-rules' option now generates working makefiles even
-    for the uncommon `make' implementations that do not support the
-    nested-variables extension to POSIX 2008.  For such `make'
+  - The 'silent-rules' option now generates working makefiles even
+    for the uncommon 'make' implementations that do not support the
+    nested-variables extension to POSIX 2008.  For such 'make'
     implementations, whether a build is silent is determined at
     configure time, and cannot be overridden at make time with
-    `make V=0' or `make V=1'.
+    "make V=0" or "make V=1".
 
   - Vala support now works better in VPATH setups.
 
@@ -1282,8 +1639,8 @@ New in 1.9:
     tar-pax.  The new option filename-length-max=99 helps diagnosing
     filenames that are too long for tar-v7.  (PR/414)
 
-  - Variables aumented with `+=' are now automatically flattened (i.e.,
-    trailing backslashes removed) and then wrapped around 80 colummns
+  - Variables augmented with `+=' are now automatically flattened (i.e.,
+    trailing backslashes removed) and then wrapped around 80 columns
     (adding trailing backslashes).  In previous versions, a long series
     of
       VAR += value1
@@ -2303,7 +2660,7 @@ New in 0.20:
 
 -----
 
-Copyright (C) 1995-2012 Free Software Foundation, Inc.
+Copyright (C) 1995-2013 Free Software Foundation, Inc.
 
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by