-* 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').
+For planned incompatibilities in a future Automake 2.0 release,
+please see NEWS-2.0 and start following the advice there now.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----
-Copyright (C) 1995-2020 Free Software Foundation, Inc.
+Copyright (C) 1995-2021 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
--- /dev/null
+This file (NEWS-2.0) lists several incompatibilities planned for a
+future Automake 2.0 release.
+
+However, the (few) current Automake maintainers have insufficient interest
+and energy to pursue the 2.0 release. We have not even reviewed all
+existing bugs. New maintainers are needed! For more information about
+helping with Automake development:
+https://lists.gnu.org/archive/html/automake/2021-03/msg00018.html
+
+Therefore, there is no ETA for Automake 2.0, but it is not likely to be
+any time soon. So moving these future issues to a separate file seemed
+warranted. For more info, see the ./PLANS/ directory.
+
+
+* 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', but that will no longer be the case
+ for Automake 2.0.
+
+ - Automake 2.0 will require Autoconf 2.71 or later. Exact
+ dependencies are unknowable at ths time.
+
+ - 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.
+
+ In 2020, config.guess was changed by its then-maintainer to require
+ $(...); the ensuing bug reports and maintenance hassle
+ (unfortunately the changes have not been reverted) are a convincing
+ argument that we should not require a POSIX shell until Solaris 10,
+ at least, is completely gone from the world.
+
+ - 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').
+
+-----
+
+Copyright (C) 1995-2021 Free Software Foundation, Inc.
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program. If not, see <https://www.gnu.org/licenses/>.