[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Automake 1.16 released
From: |
Eric Dorland |
Subject: |
Re: GNU Automake 1.16 released |
Date: |
Fri, 2 Mar 2018 01:51:54 -0500 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
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
- Re: GNU Automake 1.16 released,
Eric Dorland <=