NEWS-future - automake - Git at Google


            
            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-2026 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/>.
	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-2026 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/>.