Edit

kc3-lang/automake/NEWS-future

Branch :

  • Show log

    Commit

  • Author : Bruno Haible
    Date : 2025-05-31 10:36:16
    Hash : 901aa24b
    Message : doc: Reference POSIX:2024 for rm -f future requirement. * NEWS-future: The previously "next" POSIX version is the current POSIX (2024) now, requiring rm -f to be a no-op.

  • NEWS-future
  • 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/>.