GNU Automake 1.15 released

[Stefano Lattarini]

We are pleased to announce the GNU Automake 1.15 minor release.

This much-needed, bug-fixing release comes after a whole year of
stalling and inactivity in the Automake development.  It fixes
several bugs (some recent, some long-standing) of minor and medium
severity.

The most important and subtle of those bugs is bug#18286: "make distcheck"
could sometimes fail to detect files missing from the distribution tarball,
in case such "forgotten" files were generated files explicitly placed in
$(srcdir).

Since the fix for that bug entails minor backward-incompatibilities in
the environment where "make distcheck" is run, we've decided to bump the
minor release number (from 1.14 to 1.15) to forewarn the user.  Arguably,
only corner-cases should be affected -- but better safe than sorry.

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

Download here:

  ftp://ftp.gnu.org/gnu/automake/automake-1.15.tar.gz
  ftp://ftp.gnu.org/gnu/automake/automake-1.15.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: 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).
    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>

    Accordingly, AM_INIT_AUTOMAKE now expands some shell code that checks
    that the default 'rm' program in PATH satisfies this requirement,
    aborting the configure process if this is not the case.  For the
    moment, it's still possible to force the configuration process to
    succeed even with a broken 'rm', that that will no longer be the case
    for Automake 2.0.

  - 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: it will raise warnings in the "obsolete" category (but
    still no hard error of course, for compatibilities with the many, many
    packages that still relies on that variable).  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 retired
    support for them in December 2013:
    <http://www.sgi.com/services/support/irix_mips_support.html>

  - Automake 2.0 will 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.  There still is no
    certainty about this though: we'd first like to wait and see
    whether future Autoconf versions will be enhanced to guarantee
    that such a shell is always found and provided by the checks in
    ./configure.

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

* Improvements and refactorings in the install-sh script:

  - It has been modernized, and now makes the following assumptions
    *unconditionally*:
    (1) a working 'dirname' program is available;
    (2) the ${var:-value} shell parameters substitution works;
    (3) the "set -f" and "set +f" shell commands work, and, respectively,
        disable and enable shell globbing.

  - The script implements stricter error checking, and now it complains
    and bails out if any of the following expectations is not met:
    (1) the options -d and -t are never used together;
    (2) the argument passed to option -t is a directory;
    (3) if there are two or more SOURCEFILE arguments, the
        DESTINATION argument must be a directory.

* Automake-generated testsuites:

  - The default test-driver used by the Automake-generated testsuites
    now appends the result and exit status of each "plain" test to the
    associated log file (automake bug#11814).

  - The perl implementation of the TAP testsuite driver is no longer
    installed in the Automake's scripts directory, and is instead just
    distributed as a "contrib" addition.  There should be no reason to
    use this implementation anyway in real packages, since the awk+shell
    implementation of the TAP driver (which is documented in the manual)
    is more portable and has feature parity with the perl implementation.

  - The rule generating 'test-suite.log' no longer risk incurring in an
    extra useless "make all" recursive invocation in some corner cases
    (automake bug#16302).

* Distribution:

  - Automake bug#18286: "make distcheck" could sometimes fail to detect
    files missing from the distribution tarball, especially in those cases
    where both the generated files and their dependencies are explicitly
    in $(srcdir).  An important example of this are *generated* makefile
    fragments included at Automake time in Makefile.am; e.g.:

        ...
        $(srcdir)/fragment.am: $(srcdir)/data.txt $(srcdir)/preproc.sh
            cd $(srcdir) && $(SHELL) preproc.sh <data.txt >fragment.am
        include $(srcdir)/fragment.am
        ...

    If the use forgot to add data.txt and/or preproc.sh in the distribution
    tarball, "make distcheck" would have erroneously succeeded!  This issue
    is now fixed.

  - As a consequence of the previous change, "make distcheck" will run
    using '$(distdir)/_build/sub' as the build directory, rather than
    simply '$(distdir)/_build' (as it was the case for Automake 1.14 and
    earlier).  Consequently, the './configure' and 'make' invocations
    issued by the distcheck recipe now have $(srcdir) equal to '../..',
    rather than to just '..'.  Dependent and similar variables (e.g.,
    '$(top_srcdir)') are also changed accordingly.

    Thus, Makefiles that made assumptions about the exact values of the
    build and source directories used by "make distcheck" will have to
    be adjusted.  Notice that making such assumptions was a bad and
    unsupported practice anyway, since the exact locations of those
    directories should be considered implementation details, and we
    reserve the right to change them at any time.

* Miscellaneous bugs fixed:

  - The expansion of AM_INIT_AUTOMAKE ends once again with a trailing
    newline (bug#16841).  Regression introduced in Automake 1.14.

  - We no longer risk to use '$ac_aux_dir' before it's defined (see
    automake bug#15981). Bug introduced in Automake 1.14.

  - The code used to detect whether the currently used make is GNU make
    or not (relying on the private macro 'am__is_gnu_make') no longer
    risks causing "Arg list too long" for projects using automatic
    dependency tracking and having a ton of source files (bug#18744).

  - Automake tries to offer a more deterministic output for generated
    Makefiles, in the face of the newly-introduced randomization for
    hash keys order in Perl 5.18.

  - In older Automake versions, if a user defined one single Makefile
    fragment (say 'foo.am') to be included via Automake includes in
    his main Makefile.am, and defined a custom make rule to generate that
    file from other data, Automake used to spuriously complain with some
    message like "... overrides Automake target '$(srcdir)/foo.am".
    This bug is now fixed.

  - The user can now extend the special .PRECIOUS target, the same way
    he could already do with the .MAKE .and .PHONY targets.

  - Some confusing typos have been fixed in the manual and in few warning
    messages (automake bug#16827 and bug#16997).