GNU Automake 1.15 released

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 <[email protected]>, and send
general comments and feedback to <[email protected]>.

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