Re: GNU Automake 1.16 released

[Eric Dorland]

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:
> 
>   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 <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:
> 
>       <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 <address@hidden>
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93

signature.asc
Description: PGP signature