[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Automake 1.16 released
Re: GNU Automake 1.16 released
Fri, 2 Mar 2018 01:51:54 -0500
Can this release be tagged in the git repository?
* Mathieu Lirzin (address@hidden) 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:
> 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:
> 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:
> - 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
> - 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:
Eric Dorland <address@hidden>
43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
Description: PGP signature
- Re: GNU Automake 1.16 released,
Eric Dorland <=