mirror of
https://https.git.savannah.gnu.org/git/automake.git
synced 2026-01-27 09:54:25 +00:00
901aa24b81
* NEWS-future: The previously "next" POSIX version is the current POSIX (2024) now, requiring rm -f to be a no-op.
97 lines
4.8 KiB
Plaintext
97 lines
4.8 KiB
Plaintext
This file (NEWS-future) lists incompatibility issues that may happen in 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 and developers 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, and 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-incompatibility!
|
|
|
|
- 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 widespread in the wild, and is required by
|
|
POSIX as of 2024:
|
|
<https://pubs.opengroup.org/onlinepubs/9799919799/utilities/rm.html>
|
|
<https://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 this 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 compatibility with the many, many
|
|
packages that still rely 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-2025 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/>.
|