Automake test release 1.13.2b (will become 1.13.3)

[Stefano Lattarini]

We are pleased to announce the GNU Automake 1.13.2b test release.

This is bug-fixing release, fixing a couple of corner-case bugs, and
reworking the testsuite to avoid long-standing issues.  The testsuite
work might have introduced spurious failures on less-tested platforms,
so extra testing there would be appreciated.

The release of Automake 1.13.3 is planned for next Tuesday, June 4.

See below for the detailed list of changes since the previous version,
as summarized by the NEWS file.

Download here:

  ftp://alpha.gnu.org/gnu/automake/automake-1.13.2b.tar.gz
  ftp://alpha.gnu.org/gnu/automake/automake-1.13.2b.tar.xz

Please report bugs and problems to <address@hidden>,
and send general comments and feedback to <address@hidden>.

Thanks to everyone who has reported problems, contributed
patches, and helped testing Automake!

-*-*-*-

* 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).

  - 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.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~