From 2765c8943503fc1a335fa252f22a62f4fa3f9ecd Mon Sep 17 00:00:00 2001 From: Karl Berry Date: Tue, 18 May 2021 18:11:02 -0700 Subject: doc: move future 2.0 incompatibilities to separate file. * NEWS: move info to ... * NEWS-2.0: ... this new file. * Makefile.am (EXTRA_DIST): add it. --- Makefile.am | 1 + NEWS | 65 ++--------------------------------------- NEWS-2.0 | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 101 insertions(+), 62 deletions(-) create mode 100644 NEWS-2.0 diff --git a/Makefile.am b/Makefile.am index d8a9da1b5..1a5445d93 100644 --- a/Makefile.am +++ b/Makefile.am @@ -36,6 +36,7 @@ EXTRA_DIST += \ bootstrap \ GNUmakefile \ HACKING \ + NEWS-2.0 \ PLANS # We want a handful of substitutions to be fully-expanded by make; diff --git a/NEWS b/NEWS index aee9f4eb6..5e92387e2 100644 --- a/NEWS +++ b/NEWS @@ -1,64 +1,5 @@ -* 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 - ./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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3126,7 +3067,7 @@ New in 0.20: ----- -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 diff --git a/NEWS-2.0 b/NEWS-2.0 new file mode 100644 index 000000000..743138ca9 --- /dev/null +++ b/NEWS-2.0 @@ -0,0 +1,97 @@ +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: + + + + 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: + + + - 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 . -- cgit v1.2.1