Woohoo!! About time! :)

On Tue, Dec 8, 2020 at 12:14 PM Zack Weinberg <za...@panix.com> wrote:

> Hash: SHA256
> We are pleased to announce stable release 2.70 of GNU Autoconf.
> This release includes eight years of development work since the
> previous release, 2.69.  Noteworthy changes include support for the
> 2011 revisions of the C and C++ standards, support for reproducible
> builds, improved support for cross-compilation, improved compatibility
> with current compilers and shell utilities, more efficient generated
> shell code, and many bug fixes.  See below for a detailed list of
> changes since the previous version, 2.69, as summarized by the NEWS
> file.
> Unfortunately, we were not able to maintain perfect backward
> compatibility with existing Autoconf scripts.  Caution is advised when
> upgrading.  The list of changes, below, includes detailed explanations
> and advice for all of the compatibility problems we know about.
> Please report bugs and problems with this release to the Savannah bug
> tracker:
>    https://savannah.gnu.org/support/?func=additem&group=autoconf
> Please also send general comments and feedback to <autoc...@gnu.org>.
> We would like to thank everyone who has contributed patches, reported
> problems, and helped testing Autoconf in the past decade.
> - -*-*-*-
> Here are the compressed sources:
>   https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.gz   (2.0MB)
>   https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.xz   (1.3MB)
> Here are the GPG detached signatures[*]:
>   https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.gz.sig
>   https://ftpmirror.gnu.org/autoconf/autoconf-2.70.tar.xz.sig
> Use a mirror for higher download bandwidth:
>   https://www.gnu.org/order/ftp.html
> [*] Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact.  First, be sure to download both the .sig file
> and the corresponding tarball.  Then, run a command like this:
>   gpg --verify autoconf-2.70.tar.gz.sig
> If that command fails because you don't have the required public key,
> then run this command to import it:
>   gpg --keyserver keys.gnupg.net --recv-keys 91FCC32B6769AA64
> and rerun the 'gpg --verify' command.
> This release was bootstrapped with the following tools:
>   Automake 1.16.3
> - -*-*-*-
> * Noteworthy changes in release 2.70 (2020-12-08) [stable]
> ** Backward incompatibilities:
> *** Warnings about obsolete constructs are now on by default.
>   These warnings can be turned off with ‘-Wno-obsolete’.
>   Many of these warnings advise maintainers to run autoupdate.
>   Be aware that autoupdate cannot solve all backward compatibility
>   problems, and cannot completely solve all of the problems it does
>   address.  A configure script edited by autoupdate is likely to
>   need further manual fix-ups.
> *** Many macros have become pickier about argument quotation.
>   If you get a shell syntax error from your generated configure
>   script, or seemingly impossible misbehavior (e.g. entire blocks of
>   the configure script not getting executed), check first that all
>   macro arguments are properly quoted. The “M4 Quotation” section of
>   the manual explains how to quote macro arguments properly.
>   It is unfortunately not possible for autoupdate to correct
>   quotation errors.
> *** Many macros no longer AC_REQUIRE as many other macros as they used to.
>   This can expose several classes of latent bugs.  These are the ones
>   we know about:
>    - Make sure to explicitly invoke all of the macros that set result
>      variables used later in the configure script, or in generated
>      Makefiles.
>    - Autoconf macros that use AC_REQUIRE are not safe to use in shell
>      control-flow constructs that appear outside of macros defined by
>      AC_DEFUN.  Use AS_IF, AS_CASE, etc. instead.  (See the
>      “Prerequisite Macros” section of the manual for details.)
>      The set of macros that use AC_REQUIRE internally may change from
>      release to release.  The only macros that are guaranteed *not* to
>      use AC_REQUIRE are the macros for acting on the results of a
>      test: AC_DEFINE, AC_SUBST, AC_MSG_*, AC_CACHE_CHECK, etc.
>    - AC_REQUIRE cannot be applied to macros that need to be used with
>      arguments.  Instead, invoke the macro normally, with its arguments.
> *** More macros use config.sub and config.guess internally.
>   As a consequence of improved support for cross compilation (see below),
>   more macros now use the auxiliary scripts ‘config.sub’ and
> ‘config.guess’.
>   If you use any of the affected macros, these scripts must be available
>   when your configure script is run, even if you have no intention of
>   ever cross-compiling your program.
>   autoreconf will issue an error if any auxiliary scripts are needed but
>   cannot be found.  (It is not currently possible to make autoconf
>   itself issue this error.)
>   ‘autoreconf --install’ will add ‘config.sub’, ‘config.guess’, and
>   ‘install-sh’ to your source tree if they are needed.  If you are
>   using Automake, scripts added to your tree by ‘autoreconf --install’
>   will automatically be included in the tarball produced by ‘make dist’;
>   otherwise, you will need to arrange for them to be distributed
>   yourself.
>   See the “Input” section of the manual for more detail, including
>   where to get the auxiliary scripts that may be needed by autoconf macros.
> *** Setting CC to a C++ compiler is no longer supported.
>   The C and C++ languages have diverged enough that we can no longer
>   guarantee that test C programs will be processed as intended by a
>   C++ compiler.  In this release, configure will proceed anyway, but
>   many test results will be incorrect.  In a future release, we may
>   make AC_PROG_CC error out if it detects that CC is a C++ compiler.
>   See the “Language Choice” section of the manual for instructions on
>   how to write configure scripts for C++ programs, and for programs
>   with code in more than one language.
> *** Running configure tests with warnings promoted to errors is not
> supported.
>   For instance, setting ‘CC="gcc -Werror"’ on the configure command
>   line, or adding -Werror to CFLAGS early in the configure script when
>   the compiler recognizes this option, is very likely to cause
>   subsequent tests to fail.
>   This has never been guaranteed to work; the code generated by
>   AC_CHECK_FUNC, for instance, is incorrect by a strict reading of the
>   original 1989 C standard, and has been ever since that macro was
>   introduced.  Problems are more likely with newer, pickier compilers.
>   To enable compiler warnings and/or warnings-as-errors mode for your
>   own code, we currently recommend a dedicated Makefile variable
>   (e.g. ‘WARN_CFLAGS’) that is set by AC_SUBST when appropriate.
>   The Gnulib ‘warnings’ and ‘manywarnings’ modules can help with this.
>   We plan to add core support for probing for useful sets of compiler
>   warnings in a future release.
> *** Including confdefs.h manually may cause test failures.
>   This has never been necessary; confdefs.h is automatically included
>   at the beginning of all test programs (by AC_LANG_SOURCE).  Because
>   of the way confdefs.h is generated and used, it is not practical to
>   give it a multiple inclusion guard.  Therefore, if you include it
>   yourself, all of its definitions will be scanned twice.
>   Historically this has not been a problem, because confdefs.h only
>   makes macro definitions, and the C standard allows redefinitions
>   of macros as long as they’re exactly the same, but newer, pickier
>   compilers may complain anyway (see for instance GCC bug 97998).
> *** Older versions of automake and aclocal (< 1.8) are no longer supported.
> *** AC_CONFIG_SUBDIRS no longer directly supports Cygnus configure.
>   If you are still using an Autoconf script to drive configuration of
>   a multi-package build tree where some subdirectories use Cygnus
>   configure, copy or link $ac_aux_dir/configure into each subdirectory
>   where it is needed.  Please also contact us; we were under the
>   impression nobody used this very old tool anymore.
> *** AC_CHECK_HEADER and AC_CHECK_HEADERS only do a compilation test.
>   This completes the transition from preprocessor-based header tests
>   begun in Autoconf 2.56.
>   The double test that was the default since Autoconf 2.64 is no
>   longer available.  You can still request a preprocessor-only test
>   by specifying [-] as the fourth argument to either macro, but this
>   is now deprecated.  If you really need that behavior use
> *** AC_INCLUDES_DEFAULT assumes an ISO C90 compliant C implementation.
>   Specifically, it assumes that the ISO C90 header <stddef.h>
>   is available, without checking for it, and it does not include
>   the pre-standard header <memory.h> at all.  If the POSIX header
>   <strings.h> exists, it will be included, without first testing
>   whether both <string.h> and <strings.h> can be included in the
>   same source file.
>   AC_INCLUDES_DEFAULT still checks for the existence of <stdlib.h>,
>   <string.h>, and <stdio.h>, because these headers may not exist
>   in a “freestanding environment” (a compilation mode intended for OS
>   kernels and similar, where most of the features of the C library are
>   optional).  Most programs need not use ‘#ifdef HAVE_STDLIB_H’ etc in
>   their own code.
>   For compatibility’s sake, the C preprocessor macro STDC_HEADERS
>   will be defined when both <stdlib.h> and <string.h> are available;
>   however, <stdarg.h> and <float.h> are no longer checked for
>   (these, like <stddef.h>, are required to exist in a freestanding
>   environment).  New code should not refer to this macro.
>   Future releases of Autoconf may reduce the set of headers checked
> *** AS_ECHO and AS_ECHO_N unconditionally use ‘printf’.
>   This is substantially simpler, more reliable, and, in most cases,
>   faster than attempting to use ‘echo’ at all.  However, if ‘printf’
>   is not a shell builtin, configure scripts will run noticeably
>   slower, and if ‘printf’ is not available at all, they will crash.
>   The only systems where this is known to be a problem are extremely
>   old, and unlikely to be able to handle modern C programs for other
>   reasons (e.g. not having a C90-compliant compiler at all).
> *** Configure scripts require support for $( ... ) command substitution.
>   This POSIX shell feature is approximately the same age as
>   user-defined functions, but there do exist shells that support
>   functions and not $( ... ), such as Solaris 10 /bin/sh.
>   Configure scripts will automatically locate a shell that supports
>   this feature and re-execute themselves with it, if necessary, so
>   the new requirement should be transparent to most users.
>   In this release, most of Autoconf’s code still uses the older `...`
>   notation for command substitution.
> *** AC_INIT now trims extra white space from its arguments.
>   For instance, AC_INIT([  GNU  Hello  ], [1.0]) will set PACKAGE_NAME
>   to “GNU Hello”.
> *** Macros that take whitespace-separated lists as arguments
>     now always expand macros within those arguments.
>   Formerly, these macros would *usually* expand those arguments, but
>   the behavior was not reliable nor was it consistent between autoconf
>   and autoheader.
>   Macro expansion within these arguments is deprecated; if expansion
>   changes the list, a warning in the “obsolete” category will be
>   emitted.  Note that ‘dnl’ is a macro.  Putting ‘dnl’ comments inside
>   any argument to an Autoconf macro is, in general, only supported
>   when that argument takes more Autoconf code (e.g. the ACTION-IF-TRUE
>   argument to AC_COMPILE_IFELSE).
>   The affected macros are AC_CHECK_FILES, AC_CHECK_FUNCS,
> *** AC_FUNC_VFORK no longer ignores a signal-handling bug in Solaris 2.4.
>   This bug was being ignored because Emacs wanted to use ‘vfork’ on
>   Solaris 2.4 anyway, but current versions of Emacs have dropped
>   support for Solaris 2.4.  Most programs will want to avoid ‘vfork’
>   on this OS because of this bug.
> *** AC_FUNC_STRERROR_R assumes strerror_r is unavailable if it’s not
> declared.
>   The fallback technique it used to probe strerror_r’s return type
>   when the function was present in the C library, but not declared by
>   <string.h>, was fragile and did not work at all when cross-compiling.
>   The systems where this fallback was necessary were all obsolete.
>   Programs that use AC_FUNC_STRERROR_R should make sure to test the
>   preprocessor macro HAVE_DECL_STRERROR_R before using strerror_r at all.
> *** AC_OPENMP can’t be used if you have files named ‘mp’ or ‘penmp’.
>   Autoconf will now issue an error if AC_OPENMP is used in a configure
>   script that’s in the same directory as a file named ‘mp’ or ‘penmp’.
>   Configure scripts that use AC_OPENMP will now error out upon
>   encountering files with these names in their working directory
>   (e.g. when the build directory is separate from the source directory).
>   If you have files with these names at the top level of your source
>   tree, we recommend either renaming them or moving them into a
>   subdirectory.  See the documentation of AC_OPENMP for further
>   explanation.
> ** New features
> *** Configure scripts now support a ‘--runstatedir’ option.
>   This defaults to ‘${localstatedir}/run’.  It can be used, for
>   instance, to place per-process temporary runtime files (such as pid
>   files) into ‘/run’ instead of ‘/var/run’.
> *** autoreconf will now run gtkdocize and intltoolize when appropriate.
> *** autoreconf now recognizes AM_GNU_GETTEXT_REQUIRE_VERSION.
>   This macro can be used with gettext 0.19.6 or later to specify
>   a *minimum* version requirement for gettext, instead of the *fixed*
>   version requirement specified by AM_GNU_GETTEXT_VERSION.
> *** autoheader handles secondary config headers better.
>   It is no longer necessary to duplicate AC_DEFINE templates in the
>   main configuration header for autoheader to notice them.
> *** AC_PROG_CC now enables C2011 mode if the compiler supports it.
>   If not, it will fall back to C99 and C89, as before.  Similarly,
>   AC_PROG_CXX now enables C++2011 if available, falling back on C++98.
> *** New macro AC_C__GENERIC tests for C2011 _Generic support.
> *** AC_C_VARARRAYS has been aligned with C2011.
>   It now defines __STDC_NO_VLA__ if variable-length arrays are not
>   supported but the compiler does not define __STDC_NO_VLA__.
>   For backward compatibility with Autoconf 2.61-2.69 AC_C_VARARRAYS
>   still defines HAVE_C_VARARRAYS, but this result macro is obsolescent.
> *** New macro AC_CONFIG_MACRO_DIRS.
>   This macro can be used more than once and accepts a list of
>   directories to search for local M4 macros.  With Automake 1.13 and
>   later, use of this macro eliminates a reason to use ACLOCAL_AMFLAGS
>   in Makefile.am.
>   The older AC_CONFIG_MACRO_DIR, which could only be used once, is
>   still supported but considered deprecated.
> *** AC_USE_SYSTEM_EXTENSIONS knows about more extensions to enable.
>   System extensions will now be enabled on HP-UX, macOS, and MINIX.
>   Optional ISO C library components (e.g. decimal floating point) will
>   also be enabled.
> *** New compatibility macro AC_CHECK_INCLUDES_DEFAULT.
>   This macro runs the checks normally performed as a side-effect by
>   AC_INCLUDES_DEFAULT, if they haven’t already been done.  Autoupdate
>   will replace certain obsolete constructs, whose only remaining
>   useful effect is to trigger those checks, with this macro.  It is
>   unlikely to be useful otherwise.
> *** AC_REQUIRE_AUX_FILE has been improved.
>   Configure scripts now check, on startup, for the availability of all
>   the aux files that were mentioned in an AC_REQUIRE_AUX_FILE
>   invocation.  This should help prevent certain classes of packaging
>   errors.
>   Also, it is no longer necessary for third-party macros that use
>   if you are using AC_CONFIG_AUX_DIR_DEFAULT *without* also using
>   AC_REQUIRE_AUX_FILE, please start using AC_REQUIRE_AUX_FILE to
>   specify the aux files you actually need, so that the check can be
>   effective.
> *** AC_PROG_LEX has an option to not look for yywrap.
>   AC_PROG_LEX now takes one argument, which may be either ‘yywrap’ or
>   ‘noyywrap’.  If it is ‘noyywrap’, AC_PROG_LEX will only set LEXLIB
>   to ‘-lfl’ or ‘-ll’ if a scanner that defines both main and yywrap
>   itself still needs something else from that library.  On the other
>   hand, if it is ‘yywrap’, AC_PROG_LEX will fail (setting LEX to ‘:’
>   and LEXLIB to nothing) if it can’t find a library that defines yywrap.
>   In the absence of arguments, AC_PROG_LEX’s behavior is bug-compatible
>   with 2.69, which did neither of the above things (see the manual for
>   details).  This mode is deprecated.
>   We encourage all programs that use AC_PROG_LEX to use the new
>   ‘noyywrap’ mode, and to define yywrap themselves, or use %noyywrap.
>   The yywrap function in lib(f)l is trivial, and self-contained
>   scanners are easier to work with.
> ** Obsolete features and new warnings
> *** Use of the long-deprecated name ‘configure.in’ for the autoconf
>     input file now elicits a warning in the “obsolete” category.
> *** Use of the undocumented internal shell variables $as_echo and
>     $as_echo_n now elicits a warning in the “obsolete” category.
>     The macros AS_ECHO and AS_ECHO_N should be used instead.
> *** autoconf will now issue warnings (in the “syntax” category)
>     if the input file is missing a call to AC_INIT and/or AC_OUTPUT.
> *** autoconf will now issue warnings (in the “syntax” category)
>     for a non-literal URL argument to AC_INIT, and for a TARNAME
>     argument to AC_INIT which is either non-literal or contains
>     characters that should not be used in file names (e.g. ‘*’).
> *** AC_PROG_CC_STDC, AC_PROG_CC_C89, AC_PROG_CC_C99 are now obsolete.
>   Applications should use AC_PROG_CC.
> *** AC_HEADER_STDC and AC_HEADER_TIME are now stubs.
>   They still define the C preprocessor macros STDC_HEADERS and
>   TIME_WITH_SYS_TIME, respectively, but they no longer check for the
>   ancient, non-ISO-C90 compliant systems where formerly those macros
>   would not be defined.  Autoupdate will remove them.
>   These macros were already labeled obsolete in the manual.
>     replaced with modern equivalents by autoupdate.
>   These macros were already labeled obsolete in the manual.
> *** AC_CONFIG_HEADER is now diagnosed as obsolete, and replaced with
>     AC_CONFIG_HEADERS by autoupdate.
>   This macro has been considered obsolete for many years and was not
>   documented at all.
> *** The macro AC_OBSOLETE is obsolete.
>   Autoupdate will replace it with m4_warn([obsolete], [explanation]).
>   If possible, macros using AC_OBSOLETE should be converted to use
>   AU_DEFUN or AU_ALIAS instead, which enables autoupdate to replace
>   them, but this has to be done by hand and is not always possible.
>   This macro has been considered obsolete for many years, but was not
>   officially declared as such.
> *** Man pages for config.guess and config.sub are no longer provided.
>   They were moved to the master source tree for config.guess and
>   config.sub.
> ** Notable bug fixes
> *** Compatible with current Automake, Libtool, Perl, Texinfo, and shells.
>   All of autoconf’s tools and generated scripts, and the build process
>   and testsuite for autoconf itself, have been tested to work
>   correctly with current versions of Automake, Libtool, Perl, Texinfo,
>   bash, ksh93, zsh, and FreeBSD and NetBSD /bin/sh.
>   Generated configure scripts are expected to work reliably with an
>   even wider variety of shells, including BusyBox sh and various
>   proprietary Unixes’ /bin/sh, as long as they are minimally compliant
>   with the Unix95 shell specification.  Notably, support for
>   shell-script functions and the ‘printf’ builtin are required.
> *** Checks compatible with current language standards and compilers.
>   Many individual macros have been improved to accommodate changes in
>   recent versions of the C and C++ language standards, and new
>   features and quirks of commonly used compilers (both free and
>   proprietary).
> *** Improved support for cross compilation.
>   Many individual macros have been improved to produce more accurate
>   results when cross-compiling.
> *** Improved robustness against unusual build environments.
>   Many bugs have been fixed where generated configure scripts would
>   fail catastrophically under unusual conditions, such as stdout being
>   closed, or $TMPDIR not being an absolute path, or the root directory
>   being mentioned in $PATH.
> *** AC_CHECK_FUNCS_ONCE and AC_CHECK_HEADERS_ONCE now support multiple
>     programming languages.  They no longer perform all checks in the
>     language active upon the first use of the macro.
> *** AC_CHECK_DECL and AC_CHECK_DECLS will now detect missing declarations
> for
>     library functions that are also Clang compiler builtins.
> *** AC_PATH_X and AC_PATH_XTRA don’t search for X11 when cross-compiling.
>   Libraries and headers found by running xmkmf or searching /usr/X11,
>   /usr/X11R7, etc. are likely to belong to a native X11 installation
>   for the build machine and to be inappropriate for cross compilation.
>   To cross-compile programs that require X11, we recommend putting the
>   headers and libraries for the host system in your cross-compiler’s
>   default search paths.  Alternatively, use configure’s --x-includes
>   and --x-libraries command line options to tell it where they are.
> *** AS_IF’s if-false argument may be empty after macro expansion.
>   This long-standing limitation broke configure scripts that used
>   macros in this position that emitted shell code in 2.69 but no
>   longer do, so we have lifted it.
> *** AC_HEADER_MAJOR detects the location of the major, minor, and
>     makedev macros correctly under glibc 2.25 and later.
> *** AC_FC_LINE_LENGTH now documents the maximum portable length of
>     “unlimited” Fortran source code lines to be 250 columns, not 254.
> *** AC_INIT and AS_INIT no longer embed (part of) the path to the
>     source directory in generated files.
>   We believe this was the only case where generated file contents
>   could change depending on the environment outside the source tree
>   itself.  If you find any other cases please report them as bugs.
> *** config.log properly escapes arguments in the header comment.
> *** config.status --config output is now quoted in a more readable fashion.
> ** Autotest enhancements
> *** Autotest provides a new macro AT_DATA_UNQUOTED, similar to AT_DATA
>     but processing variable substitutions, command substitutions and
>     backslashes in the contents argument.
> *** AC_CONFIG_TESTDIR will automatically pass EXEEXT to a testsuite (via
>     the atconfig file).
> *** AT_TESTED arguments can use variable or command substitutions,
> including
>     in particular $EXEEXT
>    These provide an official way to define testsuite-specific
>    initialization code and shell functions.
> - -*-*-*-
> Contributors to the Autoconf 2.70 release include:
> Adrian Bunk
> Akim Demaille
> Andreas Barth
> Andreas Schwab
> Ben Pfaff
> Bernhard Reutner-Fischer
> Bruno Haible
> Daniel Colascione
> Daniel Elstner
> David Hill
> Eli Schwartz
> Eric Blake
> Gary V. Vaughan
> Jannick
> Jehan
> Jim Meyering
> Jonathan Wakely
> Julien ÉLIE
> Luke Mewburn
> Matěj Týč
> Michał Górny
> Nick Alcock
> Nick Bowler
> Noah Misch
> Ondrej Dubaj
> Pádraig Brady
> Paolo Bonzini
> Patrice Dumas
> Paul Eggert
> Pavel Raiskup
> Quinn Grier
> Roger Leigh
> Ross Burton
> Serhii Popovych
> Stefano Lattarini
> Thomas Jahns
> Tom
> Vincent Lefevre
> Zack Weinberg
> iQIzBAEBCAAdFiEEgvhU885zF0uLYxdAkfzDK2dpqmQFAl/PylwACgkQkfzDK2dp
> qmQhXRAAocn7rL3+1E/JuWoZ9aAko8jKdpwZjD6FdzfQeP5CExMGE6VVDSUnql/I
> vb06SYrIGEiV6rYUqOdNNc5IX3wgxY+9hYMeoKg0hDHIESvrBnB34YZNS9ZY+Plp
> F28Gpvl0jLJ4oqWKPltTFRs4KwkVsl0YVvtnKPPIp2dbWsekfXSAReEnZS/H8u4o
> dmM59QELAyQ5iiFg083ihTvzgHJ5588cm7nm3lHCEDJ4dBuouCWOJ/yz7xjKGaec
> xnFLz1H22k2cO+AbRMBAH3dAvKKVYAjIM/MOf3MXeVigQUiaPlvRdb+NNST4bhI2
> Vv6lRgGgCtUaUXm2+I5rqcX1HFCwGuNtjvjoRoLMbosbM+WcpyQ7Gq2Iam3xt/df
> qfs3yPIUSZrJZyV0bZda9UwosI2r0msjTsOq1RqJNuD8+n0ZVw1DuYz428kizcp+
> 6BKlMRr5p+RDWxETyWuQHZcVTYpKpmyJdk7wfdzR4FEdJ0esXpg7mTNhP6P1Cec6
> WsrniTLAoIGydLEdsPEIUVX3ZnsAoLcuDx54DBjSoHebRINPceJf7/+UwjV9mt+e
> Kln1ZecQVinjeXlN2AYti0jXaAJSHyry9tWtKbbQTdU0agmMnlIpBUmP5R9nAAWr
> LVQd931lHI8vxGhtHfnoRfsmDwwJ5c16RtERHMOU+ZU1E4iutYc=
> =d68l

Reply via email to