Can this release be tagged in the git repository? * Mathieu Lirzin (m...@gnu.org) wrote: > We are pleased to announce the GNU Automake 1.16 minor release. > > This release follows 1.15.1 which was made 8 months ago. > > See below for the detailed list of changes since the > previous version, as summarized by the NEWS file. > > Download here: > > https://ftp.gnu.org/gnu/automake/automake-1.16.tar.gz > https://ftp.gnu.org/gnu/automake/automake-1.16.tar.xz > > Please report bugs and problems to <bug-autom...@gnu.org>, > and send general comments and feedback to <automake@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.16: > > * Miscellaneous changes > > - When subdir-objects is in effect, Automake will now construct > shorter object file names when no programs and libraries name > clashes are encountered. This should make the discouraged use of > 'foo_SHORTNAME' unnecessary in many cases. > > * Bugs fixed: > > - Automatic dependency tracking has been fixed to work also when the > 'subdir-object' option is used and some 'foo_SOURCES' definition > contains unexpanded references to make variables, as in, e.g.: > > a_src = sources/libs/aaa > b_src = sources/bbb > foo_SOURCES = $(a_src)/bar.c $(b_src)/baz.c > > With such a setup, the created makefile fragment containing dependency > tracking information will be correctly placed under the directories > named 'sources/libs/aaa/.deps' and 'sources/bbb/.deps', rather than > mistakenly under directories named (literally!) '$(src_a)/.deps' and > '$(src_b)/.deps' (this was the first part of automake bug#13928). > > Notice that in order to fix this bug we had to slightly change the > semantics of how config.status bootstraps the makefile fragments > required for the dependency tracking to work: rather than attempting > to parse the Makefiles via grep and sed trickeries only, we actually > invoke 'make' on a slightly preprocessed version of those Makefiles, > using a private target that is only meant to bootstrap the required > makefile fragments. > > - The 'subdir-object' option no longer causes object files corresponding > to source files specified with an explicit '$(srcdir)' component to be > placed in the source tree rather than in the build tree. > > For example, if Makefile.am contains: > > AUTOMAKE_OPTIONS = subdir-objects > foo_SOURCES = $(srcdir)/foo.c $(srcdir)/s/bar.c $(top_srcdir)/baz.c > > then "make all" will create 'foo.o' and 's/bar.o' in $(builddir) rather > than in $(srcdir), and will create 'baz.o' in $(top_builddir) rather > than in $(top_srcdir). > > This was the second part of automake bug#13928. > > - Installed 'aclocal' m4 macros can now accept installation directories > containing '@' characters (automake bug#20903) > > - "./configure && make dist" no longer fails when a distributed file depends > on one from BUILT_SOURCES. > > - When combining AC_LIBOBJ or AC_FUNC_ALLOCA with the > "--disable-dependency-tracking" configure option in an out of source > build, the build sub-directory defined by AC_CONFIG_LIBOBJ_DIR is now > properly created. (automake bug#27781) > > - The time printed by 'mdate-sh' is now using the UTC time zone to support > the reproducible build effort. (automake bug#20314) > > - The elisp byte-compilation rule now uses byte-compile-dest-file-function, > rather than byte-compile-dest-file, which was obsoleted in 2009. We expect > that Emacs-26 will continue to support the old function, but will complain > loudly, and that Emacs-27 will remove support for it altogether. > > * New features added > > - A custom testsuite driver for the Guile Scheme SRFI-64 API has been added > to the "contrib" section. This allows a more convenient way to test Guile > code without having to use low primitives such as exit status. See > SRFI-64 API specification for more details: > <https://srfi.schemers.org/srfi-64/srfi-64.html> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Eric Dorland <e...@kuroneko.ca> 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
signature.asc
Description: PGP signature
