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.1: * Bugs fixed: - 'install-sh' now ensures that nobody can cross privilege boundaries by pre-creating symlink on the directory inside "/tmp". - 'automake' does not depend on the 'none' subroutine of the List::Util module anymore to support older Perl version. (automake bug#30631) - A regression in AM_PYTHON_PATH causing the rejection of non literal minimum version parameter hasn't been fixed. (automake bug#30616) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~