Fwd: autoconf-2.69b released [beta]

Alan Coopersmith alan.coopersmith at oracle.com
Fri Jul 17 19:37:32 UTC 2020


FYI, for those X.Org components still using GNU autoconf.

	-alan-


-------- Forwarded Message --------
Subject: [developer] autoconf-2.69b released [beta]
Date: Tue, 14 Jul 2020 10:02:38 -0400 (EDT)
From: Zack Weinberg <zackw at panix.com>
Reply-To: illumos-developer <developer at lists.illumos.org>
To: autoconf at gnu.org
CC: bug-autoconf at gnu.org, autotools-announce at gnu.org, platform-testers at gnu.org, 
autoconf-archive-maintainers at gnu.org, automake at gnu.org, bug-gnulib at gnu.org, 
libtool at gnu.org, devel at lists.altlinux.org, arch-dev-public at archlinux.org, 
debian-devel at lists.debian.org, devel at lists.fedoraproject.org, 
gentoo-dev at lists.gentoo.org, opensuse-factory at opensuse.org, 
freebsd-hackers at freebsd.org, tech-userlevel at netbsd.org, tech at openbsd.org, 
developer at lists.illumos.org, devel at lists.opencsw.org, mingw-users at lists.osdn.me, 
lwn at lwn.net

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


We are pleased to announce beta release 2.69b of GNU Autoconf.

This release includes eight years of development work since the
previous release, 2.69.  See below for the detailed list of changes
since the previous version, as summarized by the NEWS file.

Because it has been such a long time, and because some of the changes
potentially break existing Autoconf scripts, we are conducting a
public beta test before the final release of version 2.70.  Please
test this beta with your autoconf scripts, and report any problems you
find to the Savannah bug tracker:

    https://savannah.gnu.org/support/?func=additem&group=autoconf

Please also send general comments and feedback to <autoconf at gnu.org>.

Please also spread this announcement widely, so that as many Autoconf
users as possible hear about it.

The final release of Autoconf 2.70 is tentatively scheduled for three
months from now.  We may make more beta releases during this period.


Here are the compressed sources:
   https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.tar.gz   (1.9MB)
   https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.tar.xz   (1.3MB)

Here are the GPG detached signatures[*]:
   https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.tar.gz.sig
   https://alpha.gnu.org/gnu/autoconf/autoconf-2.69b.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.69b.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 ED97E90E62AA7E34

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
   Automake 1.15.1

NEWS

* Noteworthy changes in release 2.69b (2020-07-13) [beta]

** config.log properly escapes arguments in the header comment;
    config.status --config output is now quoted in a more readable fashion

** Configure scripts now support a '--runstatedir' option, which
    defaults to '${localstatedir}/run', and which can be used to place
    per-process temporary runtime files (such as pid files) into '/run'
    instead of '/var/run'.

** The use of the long-deprecated name 'configure.in' for the autoconf
    input file now elicits a warning in the 'obsolete' category.

** Older version of automake and aclocal (< 1.8) are no longer supported
    by autoreconf.

** Use of printf is now recommended instead of working around bugs in
    echo.  The macros AS_ECHO and AS_ECHO_N now expand unconditionally to
    'printf "%s\n"' and 'printf %s'.

** 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.

** When checking for missing templates, autoheader now takes any
    templates defined in the inputs of secondary config headers into
    account.  This makes it possible to use AC_DEFINE for secondary
    headers without duplicating the template in the main config header.

** Many macros have been improved to expand their arguments
    once and only once.  This makes ‘autoconf’ run faster.  However, it
    may break configure scripts that did not quote all macro arguments
    properly.  The ‘M4 Quotation’ section of the manual explains how to
    quote macro arguments properly.

** Several macros that are commonly used early in a configure
    script, such as AC_PROG_CC, have been optimized and no longer
    invoke as many subroutine macros as they used to.  This can expose
    several classes of 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 internally, are not safe to
      use inside of hand-written shell conditional or looping
      constructs.  Use AS_IF, AS_CASE, AS_FOR, etc. instead.
      (See the “Prerequisite Macros” section of the manual for
      further explanation.)

      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.

** 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_CHECK_FUNCS_ONCE, AC_CHECK_HEADERS, AC_CHECK_HEADERS_ONCE,
    AC_CONFIG_MACRO_DIRS, AC_CONFIG_SUBDIRS, and AC_REPLACE_FUNCS.

** 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.

** Macros

- - New macro AC_C__GENERIC.

- - AC_C_VARARRAYS now defines __STDC_NO_VLA__ if variable-length
   arrays are not supported and if the compiler does not already
   define __STDC_NO_VLA__.  This is for compatibility with C11.
   For backward compatibility with Autoconf 2.61-2.69 AC_C_VARARRAYS
   still defines HAVE_C_VARARRAYS, but this usage is obsolescent.

- - AC_CONFIG_MACRO_DIRS
   New macro, used to declare multiple directories when looking for
   local M4 macros.  This macro overcomes some of the shortfalls in the
   older AC_CONFIG_MACRO_DIR, which could only be used once; although
   the older macro remains for compatibility with older tools.  The
   newer macro will be used by the upcoming Automake 1.13 release to
   eliminate the need to specify ACLOCAL_AMFLAGS in Makefile.am.

- - AC_PROG_CC now prefers C11 if available, falling back on C99 and
   then on C89 as before.  Similarly, AC_PROG_CXX now prefers C++11
   if available, falling back on C++98.

- - AC_PROG_CC is now defined via AC_DEFUN_ONCE, to avoid bloat in 'configure'.

- - AC_PROG_CC_STDC, AC_PROG_CC_C89, AC_PROG_CC_C99 have been marked as obsolete.
   Applications should use AC_PROG_CC.

- - AC_PROG_YACC now uses 'bison -o y.tab.c' instead of 'bison -y', so that
   by default it no longer warns about Bison extensions.  Add -Wyacc to
   YFLAGS to enable these warnings.

- - AC_USE_SYSTEM_EXTENSIONS now enables more extensions on HP-UX,
   macOS, and MINIX, as well as on systems conforming to recent
   ISO/IEC C technical reports and specifications.

- - AC_CHECK_DECL and AC_CHECK_DECLS can now report missing declarations for
   functions that are also Clang compiler builtins.

- - AC_FUNC_VFORK now checks for the signal-handling bug in Solaris 2.4 'vfork'.
   Formerly, it ignored this bug, so that Emacs could use some tricky
   code on that platform.  Solaris 2.4 has not been supported since
   2003 and nowadays it's better to omit that old trick.

- - 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

- - AC_CHECK_HEADER and AC_CHECK_HEADERS now default to doing only 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_PREPROC_IFELSE.

- - AC_INCLUDES_DEFAULT has been streamlined.  It now assumes that the
   ISO C90 headers 'stdlib.h' and 'string.h' are unconditionally
   available, and does not include the pre-standard header 'memory.h'
   at all.  If the POSIX header 'strings.h' exists, it will be
   included; it is assumed to be safe to include both 'string.h' and
   'strings.h' in the same source file.  We are not aware of any
   current system that violates any of the above assumptions.

   For compatibility's sake, the C preprocessor macros STDC_HEADERS,
   HAVE_STDLIB_H, and HAVE_STRING_H are defined unconditionally.
   These preprocessor macros should be considered obsolescent.

   Future releases of Autoconf may reduce the set of headers checked
   for by AC_INCLUDES_DEFAULT.

- - AC_HEADER_STDC and AC_HEADER_TIME are now stubs which will be
   removed from 'configure.ac' by 'autoupdate'.  For compatibility's
   sake, the stubs (and their 'autoupdate' replacements) continue to
   define the C preprocessor macros STDC_HEADERS and TIME_WITH_SYS_TIME,
   respectively, but without actually checking for the ancient systems
   where formerly those macros would not be defined.

   These macros were already labeled obsolescent in the manual.

- - New macro, AC_CHECK_INCLUDES_DEFAULT.  It causes the checks normally
   performed as a side-effect by AC_INCLUDES_DEFAULT to happen at that
   point in 'configure', 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.

- - The AC_CHECK_FUNCS_ONCE and AC_CHECK_HEADERS_ONCE macros now support
   use with multiple languages, rather than forcing all checks in the
   language used by the first encounter of the macro.

- - AS_INIT now writes only the base filename of the primary input file
   into the generated script.  This avoids embedding (part of) the path
   to the source directory in generated files, which hinders build
   reproducibility.

   We believe this was the only case where generated file contents could
   change depending on the build environment.  If you find any other cases
   please report them as bugs.

- - The obsolete and undocumented macro AC_CONFIG_HEADER is now
   diagnosed as obsolete, and replaced with AC_CONFIG_HEADERS by
   autoupdate.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEgvhU885zF0uLYxdAkfzDK2dpqmQFAl8NurcACgkQkfzDK2dp
qmQf2xAAnPiVGCDJUIQji+4zEDs67EyCVOgq36wOKcgPNdSmofJLxqW+NEgnvVVY
DQqVOk72dhFKB6cDK4kWhSztBIiMbAD3dnogtbMa/qUqa4tBnVFxcFLh46y05IEM
7QOeNO6LEjz9Jlm41NrR26yh/2Pv67EJQlWRg+PGzjd7dYk7S/UCmkGWij4tKNX5
5OFmyqtvEi57X90cxMMLwjNP4uHKOMKO3DhOycIUUOymuSoXQuh6osHhz1rsjqPH
+PUPetvPcKJCuFUq3YO4sTTyuq6VpSkrZL3KCOzIpoJQWBau4r+eMvr9BF6zHBDz
SLLRiH6zbItsY8JDrZskPn7zXrR5WT/ZXSvl/Ka0mrcWcGNfFWtThPwauCWqAhOp
BWv9G3R3m/n6/It+UfRj5iNJXmZddOt8gylxMtXsIjrlo5QZe4sqryA+AJ8K2Xvh
v+a01QNT10fmj6fi/6+8Vupxh5KD16M+9aRGUjeAMdS98ssffpCvp02GN3LJwfKY
2/0cRLLK0r5NoVJJfPQWH7yBUaCGupUzQwSuWgm2ghRfJ5BgMakdjM4mBIgB9gFi
Tjlp74szW54L7xH+DlwcBg0T/oY0FranvwM2H5d0GRn4WQHAi0FUK62ypm5ffVgg
sUckv5+VoHAl4FxdqGCMClAvzZUculd+ygGimHSW2x/tXy1wbxA=
=FxYc
-----END PGP SIGNATURE-----


More information about the xorg-devel mailing list