Mathieu Lirzin
2018-03-11 22:30:05 UTC
We are pleased to announce the GNU Automake 1.16.1 maintenance release.
This release follows 1.16 which was made 2 weeks 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.1.tar.gz
https://ftp.gnu.org/gnu/automake/automake-1.16.1.tar.xz
Please report bugs and problems to <bug-***@gnu.org>,
and send general comments and feedback to <***@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.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)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This release follows 1.16 which was made 2 weeks 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.1.tar.gz
https://ftp.gnu.org/gnu/automake/automake-1.16.1.tar.xz
Please report bugs and problems to <bug-***@gnu.org>,
and send general comments and feedback to <***@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.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)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~