Zack Weinberg [Mon, 24 Jun 2024 02:15:20 +0000 (22:15 -0400)]
New public macros AC_LOG_CMD and AC_LOG_FILE.
AC_LOG_CMD is the same as the undocumented AC_RUN_LOG, which has
existed for a very long time, renamed for consistency with
AC_LOG_FILE, which is a generalization of _AC_MSG_LOG_CONFTEST.
Zack Weinberg [Wed, 26 Jun 2024 18:42:44 +0000 (14:42 -0400)]
WIP: replace AS_ESCAPE and _AS_QUOTE with AS_QUOTE_D.
AS_ESCAPE is difficult or even impossible to use correctly,
depending on what you’re trying to do with it:
+ AS_ESCAPE([text], [`\"]) is intended to permit variable interpolation
but prevent command substitution. This does not work anymore,
because we have $(...) command substitution nowadays, Solaris 10
notwithstanding.
+ It is incorrect to leave \ or " out of the [chars] argument, but people
do this all the dang time both in our own code and in third-party code.
+ It is incorrect to put anything in [chars] besides $ ` \ ", but people
also do this. In particular, 'AS_ESCAPE([text], [\'])' *does not*
produce a correct single-quoted string, but at least one third-party
m4 macro does this anyway.
+ In most cases you need to write AS_ESCAPE(m4_dquote(m4_expand([text])))
or else M4 macros inside [text] will be expanded *after* the quotation
process is complete, and the text they expand to won’t get escaped.
*Our* code using AS_ESCAPE was diligent about this, but almost no
no third-party uses bothered.
+ Almost all uses of AS_ESCAPE are constructing double-quoted strings,
so it would be more ergonomic if it added the outermost quotes for you.
(All assertions about third-party code courtesy of
<http://codesearch.debian.net/search?q=%5CbAS_ESCAPE%5Cb+-pkg%3Aautoconf+-pkg%3Aautoconf2.69&literal=0>.)
The internal _AS_QUOTE macro is also almost impossible to use
correctly, for the above reasons plus the fact that it includes some
20-year-old *internal* backward compatibility logic that doesn’t
distinguish ${variable} from $(command) either.
Replace with a safer API:
+ New macro AS_QUOTE_S([text]) turns TEXT into a single-quoted string,
*correctly* escaping embedded single quotes, and supplying an outer
pair of quotes. Macros in TEXT are expanded once before quotation.
+ New macro AS_QUOTE_D([text], [interpolation]) turns TEXT into a
double-quoted string, supplying an outer pair of quotes. Macros in
TEXT are expanded once before quotation.
The INTERPOLATION argument is a comma-separated list of keywords
specifying what types of interpolation will be permitted:
If the argument is empty or omitted, no interpolation is allowed.
This is intentionally verbose and there is no ‘allow-all’, because
I want people to think hard about if it’s really a good idea before
enabling command substitution, and I want it to be easy to find all
the place’s it’s being used. (Almost all uses of AS_ESCAPE, both
internally and externally, want either no interpolation or only
variable interpolation.) Both `...` and $(...) are handled correctly
in all modes.
+ AS_ESCAPE is changed to map each of the valid possibilities for CHARS
to the AS_QUOTE_D interpolation mode that was probably intended,
papering over the bugs in third party macros. (For example, both
[`\"] and [`] by itself will be mapped to allow-vars mode, because
we presume that someone who wrote [‘] didn’t think it through and
there’s a latent bug.) Invalid CHARS arguments now raise an error
instead of silently doing something nonsensical. All uses trigger
a -Wobsolete warning. AS_ESCAPE cannot be autoupdated to AS_QUOTE_D
(because it’s an m4sh macro, and because autoupdate can’t edit out
the surrounding quote marks) so instead I wrote a whole bunch of
advice for manual conversion in the manual.
WIP: buggy (partially but not entirely because of the bugs in
m4_join_uniq); one internal use of AS_ESCAPE remains; need to
write tests and NEWS; unresolved design decisions including
+ should ‘allow-arithmetic’ be a third interpolation keyword, separate
from ‘allow-vars’?
+ do we want a public API for escaping *without* adding surrounding
quotes? Autotest was doing this but it didn’t particularly need to.
+ should the result of AS_QUOTE_[DS] be M4-quoted? Currently it isn’t.
+ is expand-once-then-quote [i.e. shellquote(m4_dquote(m4_expand([text])))]
the most ergonomic behavior?
Zack Weinberg [Wed, 26 Jun 2024 18:40:15 +0000 (14:40 -0400)]
WIP: new m4sugar function m4_join_uniq.
This is intended to be a pure version of m4_append_uniq,
i.e. it does all its work by expansion and not by defining macros.
It will be used by the code in the next commit.
WIP: currently has severe bugs, foreach.m4 version still needed.
* lib/m4sugar/m4sugar.m4 (m4_join_uniq, _m4_join_uniq): New macros.
* doc/autoconf.texi: Document m4_join_uniq.
* tests/m4sugar.at: Test m4_join_uniq.
Zack Weinberg [Wed, 26 Jun 2024 18:35:09 +0000 (14:35 -0400)]
Quote separators in foreach.m4 version of m4_joinall.
The entire output of m4_joinall is supposed to be quoted, including
separators, but the foreach.m4 implementation (used with M4 1.4.x)
was missing some quotes, and we didn’t notice because the test suite
wasn’t thorough enough. Fix.
* lib/m4sugar/foreach.m4 (m4_joinall): Quote each separator as it’s
emitted.
* tests/m4sugar.at (m4_join test): Expand tests of both m4_join and
m4_joinall.
Zack Weinberg [Mon, 24 Jun 2024 17:51:07 +0000 (13:51 -0400)]
Emit compat shims less often for old AS_ECHO implementation details.
The shell variables $as_echo and $as_echo_n and the substitution
variables @ECHO_C@, @ECHO_N@, and @ECHO_T@ are implementation
details of the old implementation of AS_ECHO and AS_ECHO_N
(2.69-era; before the switch to use ‘printf’). We continue
to provide them for compatibility with various third-party macros and
Makefiles that used them, even though, as far as I can tell, they were
never documented. (Someone made ECHO_C etc. substitution variables on
purpose, though.)
For $as_echo and $as_echo_n, we can tell precisely when they are
needed, because all uses are exposed to M4 macro expansion.
Therefore, emit the necessary support code on first use and not
from AS_INIT. As a side effect this means the -Wobsolete warning
only appears on the first use of each, which IMHO is polite.
For @ECHO_C@, @ECHO_N@, and @ECHO_T@, we have no way of knowing
whether a substitution variable is used, but we *do* know that
substitution variables are exclusively a configure.ac thing, so their
support code can be moved to general.m4 and emitted from AC_INIT
rather than from AS_INIT.
(It’s faintly possible that someone decided to use $ECHO_C in an
Autotest script but considering how rare it is for people to use
Autotest at all, or any other non-Autoconf application of M4sh,
I think we can worry about that when we hear about it.)
* lib/m4sugar/m4sh.m4 (_AS_ECHO_N_PREPARE): Removed.
(AS_PREPARE, _AS_PREPARE): Don’t use _AS_ECHO_N_PREPARE.
(_as_echo_var_prepare, _as_echo_n_var_prepare): New macros which
emit the -Wobsolete warning and the support code for $as_echo and
$as_echo_n respectively.
(as_echo, as_echo_n): Move to bottom of the block that sets up
the current implementation of AS_ECHO. Invoke _as_echo_var_prepare
and _as_echo_n_var_prepare, respectively, on first use.
* lib/autoconf/general.m4 (_AC_INIT_ECHO_N): New internal macro,
contains the probe code that used to be in _AS_ECHO_N_PREPARE.
AC_SUBSTs ECHO_C, ECHO_N, and ECHO_T.
(AC_INIT): Don’t AC_SUBST ECHO_C, ECHO_N, and ECHO_T here.
Invoke _AC_INIT_ECHO_N.
Zack Weinberg [Mon, 24 Jun 2024 01:10:50 +0000 (21:10 -0400)]
autoconf.texi: Don’t say that Darwin is “derived from FreeBSD.”
This is an oversimplification and is probably going to cause
more confusion than it solves.
The commit which added this text was attributed to Sevan Janiyan,
but the text itself was written by me (Zack Weinberg); I revised
the patch but did not remember to also revise the commit message.
Zack Weinberg [Sun, 23 Jun 2024 19:11:35 +0000 (15:11 -0400)]
Add ‘shell.nix’ defining Autoconf’s build dependencies in NixOS terms.
Like the existing ‘manifest.scm’, which does the same job for GNU Guix,
the point of this file is to facilitate testing Autoconf itself on NixOS:
‘nix-shell --pure shell.nix’ gives you an interactive shell with all
the necessary tools in $PATH, and nothing else.
Paul Eggert [Tue, 18 Jun 2024 04:01:59 +0000 (21:01 -0700)]
Improve wording for Y2038 and largefile probes
Problem reported by Bruno Haible in:
https://lists.gnu.org/r/bug-gnulib/2024-06/msg00181.html
* lib/autoconf/specific.m4 (_AC_SYS_YEAR2038_PROBE)
(_AC_SYS_LARGEFILE_PROBE): Improve wording of chatter.
Paul Eggert [Sat, 15 Jun 2024 15:24:05 +0000 (08:24 -0700)]
Process C23 #elifdef and #elifndef
Inspired by Collin Funk’s suggestion in:
https://lists.gnu.org/r/autoconf-patches/2024-06/msg00000.html
* bin/autom4te.in (handle_output):
* bin/autoscan.in, bin/ifnames.in (scan_c_file):
Also recognize #elifdef and #elifndef.
* tests/tools.at (ifnames): Test it for ifnames.
Paul Eggert [Sat, 1 Jun 2024 16:07:38 +0000 (09:07 -0700)]
Document Solaris ‘make’ glitch with ‘!’
* doc/autoconf.texi (Failure in Make Rules):
Document that there are some complicated exceptions to
the idea that sh -e exits if any subcommand fails.
(Command Line Prefixes): New section.
Paul Eggert [Sun, 26 May 2024 16:20:56 +0000 (09:20 -0700)]
AC_PROG_CXX now tries C++23, C++20, C++17, C++14
The recent glitch with C++11 underscores the fact that it’s
long past time for Autoconf to catch up with the C++ standards.
Add simple tests for each iteration of the C++ standard.
They can be improved later as needed. When testing for these
newer standards, do not also test for features required by earlier
standards, as this isn’t all that helpful, leads to an O(N**2)
growth of ‘configure’, and can result in problems such as the
C++11 vs C++20 bug recently fixed.
* lib/autoconf/c.m4 (_AC_CXX_CXX14_TEST_PROGRAM)
(_AC_CXX_CXX17_TEST_PROGRAM, _AC_CXX_CXX20_TEST_PROGRAM)
(_AC_CXX_CXX23_TEST_PROGRAM, _AC_CXX_CXX14_OPTIONS)
(_AC_CXX_CXX17_OPTIONS, _AC_CXX_CXX20_OPTIONS)
(_AC_CXX_CXX23_OPTIONS): New macros.
(_AC_C_C23_TEST_PROGRAM, _AC_C_C23_OPTIONS): New macros.
(_AC_PROG_CC_STDC_EDITION): Try C23 first.
(_AC_PROG_CXX_STDCXX_EDITION): Use them.
Paul Eggert [Sun, 26 May 2024 14:04:19 +0000 (07:04 -0700)]
Port C11 test to C++20
Trivial fix suggested by Peter Johansson in:
https://lists.gnu.org/r/autoconf/2024-05/msg00004.html
* lib/autoconf/c.m4 (_AC_CXX_CXX11_TEST_MAIN):
Do not test assigning u8"..." to char const *, as this
runs afoul of C++20.
Paul Eggert [Tue, 30 Apr 2024 17:26:50 +0000 (10:26 -0700)]
AC_PROG_CC now tries C23 too
As C23 is now mostly supported by GCC, it's time for
AC_PROG_CC to prefer C23 if available.
* lib/autoconf/c.m4 (_AC_C_C23_TEST_GLOBALS, _AC_C_C23_TEST_MAIN):
(_AC_C_C23_TEST_PROGRAM, _AC_C_C23_OPTIONS): New macros.
(_AC_PROG_CC_STDC_EDITION): Try C23 first.
Paul Eggert [Thu, 25 Apr 2024 21:47:20 +0000 (14:47 -0700)]
Port better to MSVC
Problems reported by Antonin Décimo in:
https://lists.gnu.org/r/autoconf/2024-04/msg00001.html
* lib/autoconf/c.m4 (_AC_C_C89_TEST_GLOBALS):
Do not test the value of __STDC__.
(_AC_C_C99_TEST_MAIN): Do not test for VLAs.
(_AC_C_C11_OPTIONS): Also test -std:c11.
Paul Eggert [Wed, 24 Apr 2024 21:47:56 +0000 (14:47 -0700)]
Port AC_SYS_LARGEFILE to C++
Problem reported by Zack Weinberg
<https://savannah.gnu.org/support/?110983>.
* lib/autoconf/specific.m4 (_AC_SYS_YEAR2038_PROBE)
(_AC_SYS_LARGEFILE_PROBE):
In chatter, say it’s a CPPFLAGS option, not a CC option.
(_AC_SYS_LARGEFILE_OPTIONS): Omit -n32, as we no longer
need to worry about IRIX.
(_AC_SYS_LARGEFILE_PROBE): Fiddle with CPPFLAGS, not CC,
and don’t worry about -n32.
Paul Eggert [Sat, 6 Apr 2024 20:01:12 +0000 (13:01 -0700)]
Improve “possibly undefined macro” diagnostic
Simplified version of a suggestion by Reuben Thomas in:
https://lists.gnu.org/r/bug-autoconf/2024-04/msg00021.html
* bin/autom4te.in (warn_forbidden): Change message wording.
* tests/tools.at (autom4te and whitespace in file names)
(forbidden tokens, exceptions): Adjust tests to match new behavior.
Paul Eggert [Wed, 7 Feb 2024 20:42:04 +0000 (12:42 -0800)]
Remove incorrect check in AC_CHECK_SIZEOF
* lib/autoconf/types.m4 (AC_CHECK_SIZEOF, AC_CHECK_ALIGNOF):
When the size or alignment cannot be determined, do not fail if
ac_cv_type_$1 is yes, as there’s no guarantee that ac_cv_type_$1
is defined, and failure here would contradict the documentation
that the size or alignment is 0 when sizeof($1)/alignof($1) cannot
be compiled. The test for ac_cv_type_$1 made sense long ago when
it was checked for in these macros, but the test has not made
sense for many years.
Paul Eggert [Wed, 17 Jan 2024 04:20:06 +0000 (20:20 -0800)]
Fix ‘long long’ checks on ancient platforms
Problem reported by Nick Bowler in:
https://lists.gnu.org/r/bug-autoconf/2024-01/msg00018.html
* lib/autoconf/types.m4 (AC_TYPE_LONG_LONG_INT)
(AC_TYPE_UNSIGNED_LONG_LONG_INT): Test for these
when K&R or c89, not when neither K&R nor C89.
This fixes a thinko that I introduced in
commit cdef0d2dad57f92301cb4baf782f8c24b01d5f1d
dated Wed Feb 16 01:29:40 2011 -0800.
Zack Weinberg [Fri, 22 Dec 2023 17:39:49 +0000 (12:39 -0500)]
Finalize NEWS for release 2.72.
Since 2.72[abcde] did not get widely used, squash all the NEWS entries
since 2.71 together, and delete things that were only of interest to
people going from a,b,c to d to e. Finalize the release date.
Zack Weinberg [Fri, 22 Dec 2023 16:22:36 +0000 (11:22 -0500)]
Save/restore AC_LANG setting in AC_PROG_CC_C_O.
All of the AC_PROG_{compiler}_C_O macros, *except* AC_PROG_CC_C_O,
wrap their test in an AC_LANG_PUSH/POP pair for the appropriate
language. https://savannah.gnu.org/support/index.php?110987 reports
that AC_PROG_CC_C_O’s not doing this can cause a configure script to
malfunction. Specifically, if a script invokes AC_PROG_CC_C_O with
AC_LANG([C++]) in effect, AC_PROG_CC_C_O still runs $CC but it passes
a .cpp source file, possibly along with C-specific options. Either
of those can cause the test to mis-detect support for -c -o.
Add an AC_LANG_PUSH/POP pair to AC_PROG_CC_C_O, ensuring we are
testing the right compiler and giving it appropriate input.
* lib/autoconf/c.m4 (AC_PROG_CC_C_O): Wrap body of test in
AC_LANG_PUSH/POP to C.
This test failure has the same root cause as described in
commit 3fbfb13e7a846e98fa931b2bce373b5b2364a11b: autom4te
regenerates the output unexpectedly because the output has
the *same* file modification timestamp as the cache file it
was generated from. Apply the same stopgap fix.
* tests/tools.at (autom4te preselections): Immediately after
running autoconf the first time, delay and then touch configure.
Move the “echo newer > newer” line after the comment that explains
what it’s for. Insert additional blank lines for readability.
Zack Weinberg [Fri, 22 Dec 2023 13:47:36 +0000 (08:47 -0500)]
Avoid a spurious test failure with shells that ignore write errors.
In a surprisingly large number of cases, the ‘printf’ shell utility
doesn’t report errors caused by writing to stdout. This can cause
a spurious test failure on systems that have this bug in ‘printf’
and also have /dev/full. Detect such systems and skip that subtest.
Problem reported by Alan Coopersmith.
* tests/torture.at (AC_CONFIG_FILES, HEADERS, LINKS and COMMANDS):
If /bin/sh’s printf doesn’t report an error on writing to /dev/full,
skip the subtests that write to /dev/full.
On file systems with coarse-grained timestamps, this test was broken by
<https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=713d9822bbfb2923115065efaefed34a0113f8a1>,
which changed autom4te's logic for deciding whether its output file is
newer than its cache file. After that commit, if their modification
times are equal, the output is considered out of date. Since both
files are created in quick succession, on file systems with coarse
timestamps (1 or 2s resolution), it is very easy for their
modification times to be equal.
As a stopgap for 2.72, in this test, force the generated configure
script’s mtime to be newer than the cache file.
* tests/tools.at (autoconf: forbidden tokens, basic): After the
second AT_MTIME_DELAY, touch configure.
Zack Weinberg [Thu, 21 Dec 2023 16:48:40 +0000 (11:48 -0500)]
testsuite: Skip tests that use aclocal or automake if they’re too old.
Old versions of aclocal and/or automake can cause several tests to
fail, for two unrelated reasons:
- when used with sufficiently new Perl they might print a “your code
has a minor bug” message on every invocation, causing tests that
check for specific output to choke
- aclocal prior to 1.11.2 does not support --system-acdir
We already had code (in each individual test) to skip tests that depend
on aclocal and/or automake when those programs were *unavailable*, or
when buggy wrapper scripts were detected (apparently some BSDs once
shipped with a wrapper that required you to set an environment variable
before ‘automake’ would do anything at all). Consolidate all of that
code into local.at and augment it to detect the above two problems.
Individual tests that require automake and/or aclocal should now
just say AT_REQUIRE_AUTOMAKE and/or AT_REQUIRE_ACLOCAL at the top.
Individual tests that run autoreconf but *don’t* need a real aclocal
should instead start with AT_SUPPRESS_ACLOCAL, which sets ACLOCAL=true
and creates a dummy aclocal.m4.
While I was at it I noticed that AT_TESTED malfunctions if you have a
shell variable in there that expands to more than one shell word, so I
removed the AT_TESTED line for $M4 $PERL etc and replaced it with a
custom report for the most important system-provided programs that the
testsuite uses. That report now also includes automake and aclocal.
This should fix the problems reported by Sevan Janiyan in
<https://lists.gnu.org/archive/html/bug-autoconf/2023-12/msg00159.html>.
Tested on x86_64-linux against automake 1.11.1, 1.11.2, 1.13.0, and 1.16.5.
* tests/local.at (AT_PREPARE_TESTS): Consolidate code to detect
availability of automake and aclocal here. Also detect Perl
warning messages that will interfere with matching on the output,
and aclocal too old to understand --system-acdir. Produce a custom
report of the versions of system-provided programs we need:
m4, perl, sh, make, and optionally automake and aclocal.
(AT_TESTED): Only list programs that are part of this package.
(AT_REQUIRE_AUTOMAKE, AT_REQUIRE_ACLOCAL, AT_SUPPRESS_ACLOCAL):
New helper macros.
* tests/fortran.at, tests/tools.at, tests/torture.at:
Use AT_REQUIRE_AUTOMAKE, AT_REQUIRE_ACLOCAL, AT_SUPPRESS_ACLOCAL
throughout, as appropriate.
Zack Weinberg [Tue, 19 Dec 2023 21:13:43 +0000 (16:13 -0500)]
Adjust --help and manpages to make it easier to find the Web manual.
Today it came to my attention that, if you don’t already know that all
the GNU manuals are readable in HTML format on gnu.org, it’s not easy
to find one starting from typical --help output and/or help2man-
generated manpages. Let’s do a little to make this easier, and have
“https://www.gnu.org/software/autoconf/manual/” appear prominently in
both the --help output and the trailer text of our generated manpages.
This uses the extended tmac.an “.MT” and “.UR” directives, which are
not universal, but I suspect anyone who’s actively using Autoconf on
an old system does not need the advice, and they can get it from
--help regardless.
* bin/autoconf.in, bin/autoheader.in, bin/autom4te.in, bin/autoreconf.in
* bin/autoscan.in, bin/autoupdate.in, bin/ifnames.in:
Refer specifically to https://www.gnu.org/software/autoconf/manual/
for the web version of the complete Autoconf manual.
* man/common.x: Likewise; also, suggest the Savannah tracker as
well as bug-autoconf for bug reports.
Zack Weinberg [Tue, 19 Dec 2023 15:07:15 +0000 (10:07 -0500)]
Run gitlog-to-changelog in source directory.
gitlog-to-changelog needs to run in the source directory so it can
find the git metadata. This was masked in many cases because “git log”
will look in parent directories for .git, but if you have your build
directory completely outside the source tree then it can’t find it.
* Makefile.am (gen-ChangeLog): Execute gitlog-to-changelog in $(top_srcdir).
Zack Weinberg [Tue, 19 Dec 2023 14:50:30 +0000 (09:50 -0500)]
Skip test of AC_SYS_YEAR2038_RECOMMENDED if system doesn’t support 64-bit time_t.
AC_SYS_YEAR2038_RECOMMENDED causes configure to fail if we can’t find
a way to activate support for 64-bit time_t. This makes its
mktests.pl test fail on systems that don’t support 64-bit time_t.
Switch to a hand-written test that’s skipped on those systems.
While I was in there I added slightly more testing of the closely
related macros AC_SYS_LARGEFILE and AC_SYS_YEAR2038.
While testing this change I noticed that AC_SYS_LARGEFILE and
AC_SYS_YEAR2038 malfunction if AC_LANG([C++]) is in effect.
The cause is too hairy to fix before the release; add a mention
to NEWS instead. (Bug <https://savannah.gnu.org/support/index.php?110983>.)
* tests/mktests.pl: Exclude AC_SYS_LARGEFILE, AC_SYS_YEAR2038, and
AC_SYS_YEAR2038_RECOMMENDED from automatic test generation.
* tests/semantics.at: Add manual tests of those macros.
Paul Eggert [Sat, 16 Dec 2023 02:21:39 +0000 (18:21 -0800)]
Fix AC_FUNC_MMAP on CheriBSD
Problem reported by Brooks Davis in:
https://lists.gnu.org/r/autoconf/2023-12/msg00022.html
* lib/autoconf/functions.m4: Don’t unmap, since we
want to test remapping something already mapped,
and unmapping breaks on CheriBSD.
Zack Weinberg [Fri, 15 Dec 2023 20:19:31 +0000 (15:19 -0500)]
Clarify error messages for misuse of m4_warn and --help for -W.
m4_warn([category], [message]) passes its arguments directly to
Autom4te::Channels::msg. If the category argument is not a recognized
“channel”, that function will crash and emit a *Perl* stack trace,
which makes it look like there’s something wrong with autoconf or
autom4te, rather than something wrong with the script.
Making matters worse, in autoconf 2.69, the manual said you could
use “all” and the empty string as the first argument to m4_warn.
As far as I can tell, neither of those was ever a valid message
channel, and the manual was corrected in 2.70, but we still got
a bug report from someone who tried it.
This patch makes us issue a nice helpful user error, instead of a
confusing internal error, when Autom4te::Channels::msg is called with
a bogus channel argument. If the bogus channel is “all” or the empty
string, that error is demoted to a -Wobsolete warning. If it is one
of the other special tokens recognized by -W, we customize the error
message, since someone might’ve thought that “none” being acceptable
to -W meant it was also acceptable to m4_warn. The --help output for
autoconf, autoheader, autom4te, and autoreconf is also adjusted to
clarify that not all of the tokens recognized by -W count as
warning categories.
(Oddly enough, the lack of filtration at the autom4te level means
m4_warn([error], […]) actually does issue an error. There’s no other
way to get exactly that effect — m4_errprintn(…) and m4_fatal(…)
both do something a little different — so I I propose to leave that
alone for now and promote it to a proper, documented feature, probably
spelled m4_error(…), post-2.72.)
Channels.pm and ChannelDefs.pm are shared with Automake. I believe
there is nothing you can write in a Makefile.am that will cause
Automake::Channels::msg to be called with an arbitrary user-supplied
channel argument, so these changes should have no visible effect on
that side of the fence.
* lib/Autom4te/Channels.pm (msg): If the channel argument is invalid,
don’t crash; report the mistake and use the ‘syntax’ channel.
(report_bad_channel): New function for reporting invalid channels.
* lib/Autom4te/ChannelDefs.pm (usage): Clarify that the list of
warning categories is exhaustive, and that “all”, “none”,
“no-CATEGORY”, and “error” are not warning categories.
Zack Weinberg [Fri, 15 Dec 2023 15:59:38 +0000 (10:59 -0500)]
config.status: handle CRLF line endings in AC_CONFIG_HEADERS input
On systems that normally use Unix line endings, if config.h.in has
somehow been generated with DOS line endings, then awk will treat
each CR character as part of the line. This breaks the regular
expressions used to edit config.h.in into config.h
To fix, manually strip trailing CRs from each “input record” before
any other processing. For consistency I also made this change to the
code dealing with AC_CONFIG_FILES substitutions. On systems that use
DOS line endings, both changes should be no-ops.
Reported by David Allsopp in <https://savannah.gnu.org/support/?110554>.
He offered a different patch, which also worked on my machine, but it
used a regular expression as the third argument to ‘split’, which
might not be portable across awk implementations (the gawk manual is
unclear). Also, it could produce a config.h with _inconsistent_ line
endings.
* lib/autoconf/status.m4 (_AC_OUTPUT_HEADERS_PREPARE): In the awk
script, strip a trailing CR from each record as the first action.
(_AC_OUTPUT_FILES_PREPARE): Likewise.
* tests/torture.at (CRLF line endings in .in files): New test.
Co-authored-by: David Allsopp <david@davidallsopp.com>
Paul Eggert [Wed, 13 Dec 2023 13:48:15 +0000 (08:48 -0500)]
AC_PROG_MKDIR_P: Fix detection of busybox mkdir.
Some versions of BusyBox mkdir respond to ‘mkdir --version’ by
printing “mkdir: unrecognized option: --version” to stderr, and then
the version message we’re looking for, also to stderr. Adjust the
pattern matching in AC_PROG_MKDIR_P to account for this.
Problem reported by Valery Ushakov.
Resolves <https://savannah.gnu.org/support/?110971>.
* lib/autoconf/programs.m4 (AC_PROG_MKDIR_P): Fix detection of busybox mkdir.
Consistently use block comments at beginning of C99 and C11 tests
Purely cosmetic improvement to the C standard version tests: Use /* */
comments above all three checks of __STDC__ and/or __STDC_VERSION__,
and make “// See if C++-style comments work” the very first // comment.
Resolves issue #110713.
* c.m4 (_AC_C_C99_TEST_GLOBALS, _AC_C_C11_TEST_GLOBALS):
Improve stylistic consistency with _AC_C_C89_TEST_GLOBALS.
Move explicit test of C++-style comments earlier.
Zack Weinberg [Mon, 11 Dec 2023 16:25:54 +0000 (11:25 -0500)]
autom4te: Don’t crash if Data::Dumper::Sortkeys is unavailable.
Commit c2ab755698db245898a4cc89149eb5df256e4bd0 added an unconditional
use of Data::Dumper’s Sortkeys method, which was added in version
2.12_01 of that module. In terms of Perl versions, it is available in
5.8.x and later, and in 5.6.2, but not in 5.6.1 or earlier. At the
time, our minimum Perl version was 5.10, but we lowered it to 5.6.0
again in 05e295b60cfdf378b7ed8c1f8563a5644d5d4689. It seems that
commit was not actually tested with 5.6.1 or earlier.
As we are only using Sortkeys to facilitate manual comparison of
autom4te.cache/requests files, we can just ignore the method lookup
failure with 5.6.[01] and everything will work fine without it.
Tested on x86_64-unknown-netbsd9.3 with perl 5.6.1.
* lib/Autom4te/C4che.pm (marshall): Ignore method lookup failure for
Data::Dumper::Sortkeys with very old perl.
* lib/Autom4te/Request.pm (marshall): Likewise.
Zack Weinberg [Mon, 4 Dec 2023 16:22:24 +0000 (11:22 -0500)]
autom4te: report subsecond timestamp support in --version
The Automake test suite wants this in order to know if it’s safe to
reduce the length of various delays for the purpose of ensuring files
in autom4te.cache are newer than the corresponding source files. We
can also take advantage of this to speed up a couple of tests in our
own testsuite.
* lib/Autom4te/FileUtils.pm: Provide (but do not export) a flag
$subsecond_mtime, indicating whether the ‘mtime’ function reports
modification time with precision greater than one second.
Reorganize commentary and import logic for clarity. Add
configuration for emacs’ perl-mode to the bottom of the file.
* bin/autom4te.in ($version): If $Autom4te::FileUtils::subsecond_mtime
is true, print “Features: subsecond-mtime” as the second line
of --version output.
* lib/autotest/general.m4: Move definitions of AS_MESSAGE_LOG_FD,
AT_JOB_FIFO_IN_FD, and AT_JOB_FIFO_OUT_FD to top level and change
the latter two to be defined using _AT_DEFINE_INIT. This enables
use of AS_MESSAGE_LOG_FD in AT_TESTS_PREPARE code.
* tests/local.at (AT_MTIME_DELAY): New utility that delays a test for
an appropriate time to ensure all files created before its use are
considered older than all files created afterward. The delay will
be as short as possible.
(AT_TESTS_PREPARE): Calculate and log the delay used by AT_MTIME_DELAY.
Only use a delay shorter than one second if the build filesystem,
our autom4te, and the automake on the PATH all support this.
(AT_CMP): En passant removal of unnecessary blank lines.
* tests/tools.at: Use AT_MTIME_DELAY, instead of sleeping for a
hardcoded interval, everywhere the delay was to control file
timestamps.
Paul Eggert [Fri, 1 Dec 2023 17:36:36 +0000 (09:36 -0800)]
Tweak Annex K doc
* doc/autoconf.texi (C and Posix Variants):
Don’t insist on C11 when talking about Annex K, as
Annex K is also present in later versions of the C standard.
Zack Weinberg [Fri, 1 Dec 2023 13:44:55 +0000 (08:44 -0500)]
testsuite: log version of shell and make as well
A lot of bugs recently have been due to unexpected changes in shell
and/or make behavior, so let’s log their versions in testsuite.log
to make it easier to figure out when that’s the problem.
Some shells don’t recognize --version but we still get an indication
in the logfile of which shell it is, e.g.
Zack Weinberg [Thu, 30 Nov 2023 20:25:45 +0000 (15:25 -0500)]
Release 2.72d [beta]
Revise all NEWS entries since 2.71 for clarity. Add an entry
to the compatibility section about the macros that no longer
have AC_PROG_{EGREP,CPP} as a side effect.
Paul Eggert [Sun, 26 Nov 2023 17:04:05 +0000 (09:04 -0800)]
Remove m4_file_append
* lib/m4sugar/m4sugar.m4 (m4_file_append): Remove.
In 2000, this undocumented macro was left in by mistake
even though all its callers were removed.
Inspired by a bug report by Ally Petitt (sr#110961).
KO Myung-Hun [Wed, 18 Oct 2023 18:00:11 +0000 (14:00 -0400)]
m4/m4.m4: Quote argument to AS_ECHO correctly.
AS_ECHO’s argument is required to be “a single shell word,”
and this more precisely means it must not be altered by shell
word splitting. In particular, if the argument contains shell
variables whose values contain whitespace then it needs to be
wrapped in "shell double quotes".
The absence of these quotes caused one of the embedded M4 scripts
to be mangled by the Autoconf 2.69 implementation of AS_ECHO.
We don’t officially support bootstrapping with an older version
of Autoconf (use the ./bootstrap script instead) but the absence
of quotes is still incorrect.
For consistency add [M4 quotes] to the use of AS_ECHO that was
shell-quoted but not M4-quoted.
* m4/m4.m4 (AC_PROG_GNU_M4): Quote argument to AS_ECHO correctly.
Zack Weinberg [Wed, 18 Oct 2023 17:23:36 +0000 (13:23 -0400)]
autom4te: OS/2 compat: Do not attempt to chmod an open file.
On OS/2, chmod(2) cannot be applied to an open file.
Instead set the desired permissions when the file is initially
created, using the PERMS argument to File::Temp::tempfile if
possible, or by manually emulating that feature if the system
perl does not provide a new enough version of File::Temp.
This has the nice side effect that we no longer need to handle
the umask manually.
* autom4te.in (tempfile_with_mode): New function.
(handle_output): Use tempfile_with_mode instead of directly using
File::Temp plus chmod.
Paul Eggert [Sat, 19 Aug 2023 02:47:06 +0000 (19:47 -0700)]
Improve INSTALL format
* doc/install.texi (Compilers and Options): Fix two @ref
instances that don’t work well when making INSTALL.
Problem noted by Gavin Smith in:
https://lists.gnu.org/r/autoconf/2023-08/msg00004.html
Fix _AC_LANG_IO_PROGRAM(C) to work with glibc 2.38 headers
Following the glibc commit glibc-2.38~268 ("libio: Add __nonnull
for FILE * arguments of fclose and freopen"), the utilization of the gcc
-fanalyzer flag in combination with the -Werror flag leads to an error
within the _AC_LANG_IO_PROGRAM(C) function:
conftest.c:14:23: error: use of possibly-NULL 'f' where non-null expected [CWE-690] [-Werror=analyzer-possible-null-argument]
* lib/autoconf/c.m4 (_AC_LANG_IO_PROGRAM): Exit upon encountering
fopen() error.
Paul Eggert [Sat, 24 Jun 2023 21:39:34 +0000 (14:39 -0700)]
Shorten and improve INSTALL
Rewrite install.texi so that INSTALL is shorter and hopefully
more useful for new installers.
* doc/install.texi: When not building the Autoconf manual, put
copyright notice at the end, and omit external references as they
do not work in INSTALL.
Avoid long URLs as they do not work well in INSTALL or
in info files. Be more consistent (though not entirely
consistent) about “system” vs “architecture”.
(System Types, Building for a different system type)
(Troubleshooting the Build Type): Coalesce into a single section
and rewrite for clarity and brevity. Mention build-aux. Do not
mention --target here as it’s too rare to make the cut.
Bruno Haible [Fri, 23 Jun 2023 15:37:35 +0000 (17:37 +0200)]
INSTALL: Clarify --build, --host, --target, and the system types.
* doc/install.texi (Compilers and Options): Add another reference.
(System Types): Renamed from System Type. Explain how to canonicalize
and how to validate a system type. Don't explain --build, --host,
--target here.
(Building for a different system type): New section.
(Troubleshooting the Build Type): New section.
(Configuring a Compiler): New section.
(configure Invocation): Mention the --host option, not the --build
option, since --build is so rarely needed.
Paul Eggert [Tue, 20 Jun 2023 20:23:19 +0000 (13:23 -0700)]
Modernize INSTALL
Problem reported for gettext bootstrap by Julien Palard in:
https://savannah.gnu.org/bugs/?62196
* doc/install.texi: Give a brief info as to how to bootstrap,
on packages built from Git rather from a distribution tarball.
Remove aging details about c99, macOS, X, HP-UX, OSF/1, Solaris,
Haiku, sun4. Improve documentation for enable/disable and
with/without options.
Paul Eggert [Mon, 19 Jun 2023 21:04:29 +0000 (14:04 -0700)]
Fix AC_SYS_LARGEFILE on GNU/Linux alpha, s390x
Problem reported by Matoro <https://bugs.gnu.org/64123>.
* lib/autoconf/specific.m4 (_AC_SYS_LARGEFILE_TEST_CODE):
New overridable macro FTYPE, to test types other than off_t.
(_AC_SYS_LARGEFILE_TEST_CODE): Test ino_t for
-D_FILE_OFFSETBITS=64 too, if no flags are needed for off_t.
Needed for GNU/Linux on alpha and s390x.
Paul Eggert [Sat, 13 May 2023 16:56:33 +0000 (09:56 -0700)]
Improve AC_SYS_YEAR2038_RECOMMENDED diagnostic
* lib/autoconf/specific.m4 (AC_SYS_YEAR2038_RECOMMENDED):
Do not recommend gcc -m64, as that likely will not work.
Problem reported by Bruno Haible in:
https://lists.gnu.org/r/bug-gnulib/2023-05/msg00060.html
Instead, mention that 32-bit time_t is not recommended
for this package, before telling the builder how
to configure with 32-bit time_t anyway.
Paul Eggert [Thu, 11 May 2023 05:57:27 +0000 (22:57 -0700)]
Fix port of AC_FUNC_MMAP
Problem reported by Matt Turner in:
https://lists.gnu.org/r/bug-autoconf/2023-05/msg00005.html
* lib/autoconf/functions.m4 (AC_FUNC_MMAP): Go back to getting the
page size, since the zero-fill test needs this after all.
However, prefer sysconf (_SC_PAGESIZE) or sysconf (_SC_PAGE_SIZE)
to getpagesize (), and use ‘long’ not ‘int’ to store the page size.
Also, declare getpagesize if it is used as a function.
Paul Eggert [Thu, 11 May 2023 00:20:49 +0000 (17:20 -0700)]
Port AC_FUNC_MMAP to more-modern systems
* lib/autoconf/functions.m4 (AC_FUNC_MMAP): Don’t call
getpagesize, as it’s tricky to configure, modern POSIX doesn’t
require it, and calling it without including <unistd.h> provokes a
compile-time error on modern systems. Instead, rework the test
to not need getpagesize. Add a FIXME comment for unnecessary
tests; I don't want to remove them now as we're too close to
a release. Remove long-obsolete comment about GNU grep.
Paul Eggert [Thu, 27 Apr 2023 01:21:48 +0000 (18:21 -0700)]
Tone down year-2038 changes
New macro AC_SYS_YEAR2038_RECOMMENDED replaces new macro
AC_SYS_YEAR2038_REQUIRED, and gives the builder an out of
specifying --disable-year2038. Remove new macro
AC_SYS_LARGEFILE_REQUIRED, which was added only for symmetry and
does not seem to have a great need.
* NEWS, doc/autoconf.texi: Document this.
* lib/autoconf/specific.m4:
Be more specific about mid-January 2038 than just Jan 2038.
(_AC_SYS_YEAR2038_PROBE): Ignore IF-NOT-DETECTED arg.
If support is not detected, merely set ac_have_year2038=no instead
of erroring out. All callers changed.
(_AC_SYS_YEAR2038_OPT_IN): Remove. All callers removed.
(AC_SYS_YEAR2038): Simplify by requiring AC_SYS_LARGEFILE
and then testing the result.
(AC_SYS_YEAR2038_REQUIRED, AC_SYS_LARGEFILE_REQUIRED): Remove.
(AC_SYS_YEAR2038_RECOMMENDED): New macro.
(_AC_SYS_LARGEFILE_PROBE): If support is not detected, merely set
ac_have_largefile=no instead of erroring out. All callers changed.
Take on the burden of invoking year2038 probe as needed.
(AC_SYS_LARGEFILE): Simplify.
Bruno Haible [Wed, 19 Apr 2023 21:17:24 +0000 (14:17 -0700)]
AC_SYS_YEAR2038_REQUIRED: Fix configure failure with MSVC.
* lib/autoconf/specific.m4 (_AC_SYS_LARGEFILE_PROBE): Distinguish the results
"support not detected" and "supported through gnulib". If the result is
"supported through gnulib", don't fail.
Paul Eggert [Sun, 9 Apr 2023 18:41:57 +0000 (11:41 -0700)]
Improve year2038, largefile option processing
* lib/autoconf/specific.m4 (_AC_SYS_YEAR2038_PROBE)
(_AC_SYS_YEAR2038_ENABLE, _AC_SYS_YEAR2038_OPT_IN)
(AC_SYS_YEAR2038, _AC_SYS_LARGEFILE_PROBE)
(_AC_SYS_LARGEFILE_ENABLE): Do not use enable_largefile to record
whether largefile is required, as ‘./configure
--disable-largefile’ sets enable_largefile=no even if largefile is
required and this disables largefile. Instead, use a separate
shell variable ac_largefile_required and test it as well.
Similarly for enable_year2038.
(_AC_SYS_LARGEFILE_ENABLE): Omit --disable-largefile help string
if year2038 is required, since largefile is a prereq for year2038.
Paul Eggert [Mon, 3 Apr 2023 16:12:40 +0000 (09:12 -0700)]
Support circa early 2022 Gnulib
Problem reported by Frederic Berat in:
https://lists.gnu.org/r/bug-rcs/2023-04/msg00001.html
* lib/autoconf/specific.m4 (_AC_SYS_LARGEFILE_TEST_INCLUDES):
Bring back for compatibility with post-2.71, pre-2.73 Gnulib.
Remove the last few internal uses of AC_EGREP_CPP.
Most of the remaining uses were converted to AC_COMPILE_IFELSE.
The use in AC_FUNC_LOADAVG becomes an AC_PREPROC_IFELSE because
we can’t be sure getloadavg.c can be _compiled_ at this point in
the build. The use in AC_C_VARARRAYS could be either _PREPROC_ or
_COMPILE_; we use _COMPILE_ because, _PREPROC_ is never used, then
we don’t have to do the “checking how to run the C preprocessor” test.
* lib/autoconf/c.m4 (AC_C_VARARRAYS): Use AC_COMPILE_IFELSE instead of
AC_EGREP_CPP.
* lib/autoconf/headers.m4 (_AC_HEADER_TIOCGWINSZ_IN_TERMIOS_H)
(_AC_HEADER_TIOCGWINSZ_IN_SYS_IOCTL_H): Likewise.
* lib/autoconf/functions.m4 (AC_FUNC_GETLOADAVG): Use AC_PREPROC_IFELSE
instead of AC_EGREP_CPP.
Another of the last few uses of AC_EGREP_CPP is to check for the ISO C
“stringification” operator. As this is a feature of C89, let’s fold
the test into the extensive C89 tests we already have, and make
AC_C_STRINGIZE just lean on AC_PROG_CC, in the same way
AC_C_PROTOTYPES does.
* lib/autoconf/c.m4 (_AC_C_C89_TEST_GLOBALS): Add test of preprocessor
stringification and token pasting.
(AC_C_STRINGIZE): Just check ac_prog_cc_stdc.
AC_TYPE_GETGROUPS is the last remaining use of AC_EGREP_HEADER in
stock Autoconf macros. It uses it only when cross compiling, as a
fallback from an AC_RUN_IFELSE check, testing for a bug in system
headers from the late 1980s or early 1990s, where gid_t *existed*
but the second argument to getgroups needed to be an array of int,
and this didn’t cause a compile error (i.e. the system headers
declare getgroups with no prototype or an incorrect prototype).
AC_FUNC_GETGROUPS also uses AC_RUN_IFELSE to test for obscure
problems specific to long-obsolete Unixes.
The downsides of AC_RUN_IFELSE and AC_EGREP_HEADER seem more severe
than the chances of someone compiling a current-generation program,
that uses getgroups, on an OS old enough to have one of the really
nasty bugs. Accordingly, this patch changes AC_FUNC_GETGROUPS to use
a host_os-based *blacklist* both in native and cross compilation.
This is limited to the two host_os values for which either our old
code, or Gnulib, documented a serious bug: ultrix* and nextstep*.
Currently it does not try to pin down the exact version ranges subject
to the bugs — that would require research by someone with access to
the full history of these OSes.
An incorrect guess by this blacklist can be overridden by setting
ac_cv_func_getgroups_works in config.site. AC_TYPE_GETGROUPS, for its
part, now does a series of regular old AC_COMPILE_IFELSE checks to
probe the prototype of getgroups, and considers that good enough.
While I was in there I noticed that AC_FUNC_GETGROUPS does not
AC_SUBST a documented output variable, and that the name of this
variable is misspelled in the manual.
* lib/autoconf/functions.m4 (AC_FUNC_GETGROUPS): Use AC_SEARCH_LIBS
to probe for getgroups. Use an AC_CANONICAL_HOST-based blacklist
for bug detection, not AC_RUN_IFELSE. AC_SUBST the GETGROUPS_LIB
output variable.
* lib/autoconf/types.m4 (AC_TYPE_GETGROUPS): Check only the prototype
of getgroups, using AC_COMPILE_IFELSE; do not use either AC_RUN_IFELSE
or AC_EGREP_HEADER.
* doc/autoconf.texi: Update to match. Correct misspelling of
GETGROUPS_LIB.
* tests.local.at (_AT_CHECK_ENV): Allow GETGROUPS_LIB output variable.
Make AC_PROG_GCC_TRADITIONAL a compatibility alias for AC_PROG_CC.
This macro is one of the last remaining internal uses of AC_EGREP_CPP.
It has only ever done anything useful with GCC, and GCC dropped
support for ‘traditional’ compilation in version 3.3 (released 2003)
so I do not think it is worth trying to preserve.
* lib/autoconf/c.m4 (AC_PROG_GCC_TRADITIONAL): Make into a
compatibility alias for AC_PROG_CC, similar to AC_PROG_CC_STDC.
* lib/autoconf/general.m4 (AC_EGREP_CPP): Remove stale comment.
* doc/autoconf.texi, NEWS: Document this change.
* tests/mktests.pl: Exclude AC_PROG_GCC_TRADITIONAL from
autoupdate tests.
AC_TYPE_UID_T uses AC_EGREP_HEADER to search sys/types.h for
occurrences of the string ‘uid_t’ and, if found, assumes both
uid_t and gid_t are available. This would be better done using
a pair of AC_CHECK_TYPE operations.
I also converted two uses of old-style AC_CHECK_TYPE, immediately
below, to new-style. (There are probably other old-style uses in
this file, I only did the ones I happened to see.)
* lib/autoconf/types.m4 (AC_TYPE_UID_T): Check for uid_t and gid_t,
separately, using AC_CHECK_TYPE, instead of grepping sys/types.h.
(AC_TYPE_SIZE_T, AC_TYPE_SSIZE_T): Use new-style AC_CHECK_TYPE.
AC_XENIX_DIR is an obsolete macro, defined as AC_HEADER_DIRENT plus
code to make absolutely sure configure scripts that depended on a
shell variable internal to the original (2.13 era) definition of
AC_XENIX_DIR are not broken by autoupdate. (That variable had the
temptingly public-sounding name “XENIX.”) This compatibility code
uses AC_EGREP_CPP, which is itself discouraged for use in new
configure scripts.
(N.B. codesearch.debian.net does not find any uses whatsoever of
this macro, nor any code in an .ac or .m4 file that depends on the
XENIX variable.)
Change the compatibility code to use AC_CANONICAL_HOST instead,
and clarify which pieces of the code inserted by autoupdate are
probably still necessary.
* lib/autoconf/specific.m4 (AC_XENIX_DIR): Set XENIX variable
based on value of host_os. Clarify what manual cleanup is
recommended after autoupdate replaces this obsolete macro.
Paul Eggert [Sun, 2 Apr 2023 03:25:13 +0000 (20:25 -0700)]
Support underquoted callers better
Problem reported bh Khem Raj for mcpp 2.7.2 (2008) in:
https://lists.gnu.org/r/autoconf/2023-04/msg00001.html
* lib/autoconf/programs.m4 (_AC_PATH_PROG_FLAVOR_GNU):
Add two ‘@%:@(’s to cater to underquoted callers.
* lib/m4sugar/m4sh.m4 (_AS_PATH_WALK): Use quadrigraph instead of
‘#’, for underquoted callers.
Paul Eggert [Sat, 1 Apr 2023 23:44:03 +0000 (16:44 -0700)]
Fix timing bug on high-speed builds
Problem reported by Bogdan via Jacob Bachmeyer in:
https://lists.gnu.org/r/autoconf/2023-04/msg00002.html
* bin/autom4te.in: If a file timestamp equals a dependency’s
timestamp, consider the file to be out of date. Although this may
result in extra work, it fixes some rare timing bugs.
Paul Eggert [Fri, 31 Mar 2023 17:55:29 +0000 (10:55 -0700)]
Go back to requiring only Perl 5.6+ for users
Commit 61901a1a14fd50c03cfb1529d091554376fef286 dated 2022-07-10
bumped the Perl requirement to 5.10 or later, because
commit 3a9802d60156809c139e9b4620bf04917e143ee2 dated 2021-08-31
added code using Time::HiRes’s ‘stat’ function, a feature
added in Perl 5.8.9+ or Perl 5.10+, and it was hard
to find Perl 5.8.9 hosts to test with. Also, requiring Perl 5.10
meant that we could then use operators like Digest::SHA, the // and
//= operators, the regexp \K escape, and ‘state’ variables.
However, that Time::HiRes code, which was taken from Automake, has
recently been made optional by Automake, and it now works again with
Perl 5.6. And Autoconf is not yet using any other post-5.6 feature,
except when developers run help-extract.pl (something Autoconf users
do not use). So relax the Autoconf user requirement back to 5.6 as it
was in Autoconf 2.71; although Autoconf developers will need 5.10 or
better, Autoconf users can get by with 5.6.
I ran into this problem when testing the Autoconf release candidate on
Solaris 10, which has Perl 5.8.4. Oracle says Solaris 10’s
end-of-life is January 2024, so it’s still (barely) a viable porting
target. Of course with Solaris 10 one must install a recent-enough
GNU m4, but adding a requirement to also install a recent-enough Perl
is a new barrier, and if it’s not needed then it might be better to
wait until it is needed (or until 2024 arrives).
* NEWS: Update news item about Perl 5.6 vs 5.10.
* README-hacking: Bump Perl recommendation to 5.10.
* build-aux/fetch.pl: Do not munge imported code to require 5.10.
Paul Eggert [Fri, 31 Mar 2023 17:46:20 +0000 (10:46 -0700)]
Cater to programs misusing AC_EGREP_HEADER
Problem reported by Frederic Berat in:
https://lists.gnu.org/archive/html/autoconf/2022-11/msg00127.html
* lib/autoconf/programs.m4 (AC_PROG_EGREP): Also set
EGREP_TRADITIONAL and ac_cv_path_EGREP_TRADITIONAL.
* tests/c.at (AC_PROG_EGREP and AC_EGREP_HEADER):
New test, taken from Frederic Berat’s email in:
https://lists.gnu.org/r/autoconf/2023-03/msg00043.html
Jim Meyering [Mon, 27 Mar 2023 05:08:02 +0000 (22:08 -0700)]
tests: avoid an unwarranted test failure
* tests/autotest.at (parallel autotest and signal handling): This
test would consistently fail due to an exit status of 0. That was
considered failure because the test required a SIGHUP-indicating
exit status. However, an status of 0 is perfectly fine, too, so
accept that.
Jim Meyering [Sun, 26 Mar 2023 05:07:19 +0000 (22:07 -0700)]
build: run "make fetch", which updated these:
Preparing to make a pre-release snapshot, update these:
* build-aux/announce-gen: Update from gnulib
* build-aux/gnupload: Likewise.
* build-aux/texinfo.tex: Update from texinfo.
projects / thirdparty / autoconf.git / log
