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 <bug-autom...@gnu.org>, and send general comments and feedback to <autom...@gnu.org>. 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). _______________________________________________ GNU Announcement mailing list <info-gnu@gnu.org> https://lists.gnu.org/mailman/listinfo/info-gnu
