Re: [PATCH] AC_FUNC_MALLOC: fix cross compilation to musl

On Wed, May 15, 2024, at 11:49 AM, Alyssa Ross wrote: > This check returned yes for me on musl 1.2.3 on aarch64-unknown-linux- > musl. Thanks! I verified by code inspection that all three of musl libc's malloc implementations return a non-NULL pointer for malloc(0), and committed your patch. zw

Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

On Fri, Dec 22, 2023, at 8:22 AM, Zack Weinberg wrote: > (But I'll also see if it's practical to mark this test as an expected > failure on systems where the write error isn't detected.) Thus. Tested only on Linux. I don't have access to a machine that has *both* /dev/full and a buggy pr

Re: [PATCH] [committed] autom4te: Don’t crash if Data::Dumper::Sortkeys is unavailable.

On Tue, Dec 19, 2023, at 7:13 PM, Paul Eggert wrote: > > Solaris 10: the OS version that refuses to die If I ever get around to CI for autoconf, one of the workers is going to be set up with "Heirloom" utilities, the least capable shell I can find that still passes M4sh's acceptance test,

[PATCH v2, committed] 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

Re: [bug#67841] [PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

On Fri, Dec 15, 2023, at 6:52 PM, Karl Berry wrote: > Hi Zack, > > Since this touches code shared between Autoconf and Automake, I'm not > checking it in yet and I'm requesting comments from both sides of the > fence. > > Well, it seems good to me in principle, FWIW. I don't think this

Re: [bug#67841] [PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

On Fri, Dec 15, 2023, at 7:08 PM, Jacob Bachmeyer wrote: > Zack Weinberg wrote: >> [...] >> Also, there’s a perl 2.14ism in one place (s///a) which I need >> to figure out how to make 2.6-compatible before it can land. ... >> + $q_channel =~ s/([^\x20-\x7e])/"\

[PATCH] Clarify error messages for misuse of m4_warn and --help for -W.

In autoconf 2.69, the manual said that you could use “all” and the empty string as the first argument to m4_warn. As far as I can tell this was never actually true, and the manual was corrected in 2.70, but we still got a bug report from someone who tried it and got a confusing internal error

[committed PATCH] 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

[PATCH] AC_PROG_MKDIR_P: Fix detection of busybox mkdir.

From: Paul Eggert 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

[PATCH] [committed] Consistently use block comments at beginning of C99 and C11 tests

From: Detlef Riekenberg 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,

[PATCH] [committed] 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

Re: [RFC PATCH]: autom4te: report subsecond timestamp support in --version

On Tue, Dec 5, 2023, at 11:30 PM, Jacob Bachmeyer wrote: > Zack Weinberg wrote: >> $ autom4te --version >> autom4te (GNU Autoconf) 2.71 >> Features: subsecond-timestamps >> >> Copyright (C) 2021 Free Software Foundation, Inc. >> License GPLv3+/Autocon

[PATCH v2, committed] 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. *

Re: [RFC PATCH]: autom4te: report subsecond timestamp support in --version

On Mon, Dec 4, 2023, at 7:26 PM, Jacob Bachmeyer wrote: > Now that I have seen the actual patch, yes, this test should be > accurate. The test in the main autom4te script will also work, even > if there is a mismatch between the script and its library Good. > This appears to be misaligned with

[RFC PATCH]: 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. * lib/Autom4te/FileUtils.pm: Provide (but do not export) a flag $subsecond_mtime, indicating

Re: Recognize the *-*-windows* config triplets introduced on 2023-06-26

On Fri, Dec 1, 2023, at 12:21 AM, Bruno Haible wrote: > Hi, > > Through these two commits to config.sub > > https://git.savannah.gnu.org/gitweb/?p=config.git;a=commitdiff;h=91f6a7f616b161c25ba2001861a40e662e18c4ad > >

Re: [PATCH 1/2] Fix detection of GNU M4 on mksh

On Wed, Oct 18, 2023, at 10:09 AM, KO Myung-Hun wrote: > Zack Weinberg wrote: >> Details please? > > Commit message was not enough ? I'm afraid not. I needed to know everything you say in the next two paragraphs: > $ac_snip2 contains NL. And in order to print it, `print -r --'

Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2

On Wed, Oct 18, 2023, at 10:21 AM, KO Myung-Hun wrote: > Zack Weinberg wrote: >> I don’t want to have code in Autoconf that is only safe because of >> non-obvious details of the context it’s used in. People might >> reuse the code in a different context where it’s *not* safe,

Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2

On Tue, Oct 17, 2023, at 2:58 PM, Paul Eggert wrote: > On 10/17/23 11:16, Zack Weinberg wrote: ... >> you have to be exquisitely careful, or a malicious concurrent process >> might be able to trick you into overwriting some file elsewhere on >> the filesystem. ...

Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2

On Sun, Oct 15, 2023, at 3:43 AM, KO Myung-Hun wrote: > Zack Weinberg wrote: >> On Sat, Oct 14, 2023, at 9:19 AM, KO Myung-Hun wrote: >>> * bin/autom4te.in (handle_output): Ignore setting mode failure on OS/2. >> >> Not OK, for two reasons: ... > How about this ?

Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2

On Sat, Oct 14, 2023, at 1:27 PM, Russ Allbery wrote: > The standard Perl command corelist -a tells you the versions of > that module that shipped with each version of Perl. The first version of > Perl that included a version of File::Temp later than 0.2310 was Perl > 5.33.3 (which included

Re: [PATCH 1/2] Fix detection of GNU M4 on mksh

On Sun, Oct 15, 2023, at 2:58 AM, KO Myung-Hun wrote: > Zack Weinberg wrote: >> On Sat, Oct 14, 2023, at 9:19 AM, KO Myung-Hun wrote: >>> * m4/m4.m4 (AC_PROG_GNU_M4): Double-quotes $ac_snip2. >> Please explain why it isn't also necessary to add double quotes >>

Re: [PATCH 2/2] Ignore failure of setting mode on a temporary file on OS/2

On Sat, Oct 14, 2023, at 9:19 AM, KO Myung-Hun wrote: > OS/2 does not allow chmod() on an opened file. > > * bin/autom4te.in (handle_output): Ignore setting mode failure on OS/2. Not OK, for two reasons: (1) IIRC this is used to create scripts with the execute bit set in at least one place.

Re: [PATCH 1/2] Fix detection of GNU M4 on mksh

On Sat, Oct 14, 2023, at 9:19 AM, KO Myung-Hun wrote: > * m4/m4.m4 (AC_PROG_GNU_M4): Double-quotes $ac_snip2. Please explain why it isn't also necessary to add double quotes around all the other variable expansions in this check, particularly $ac_snippet and $ac_path_M4. Also, typo in your

Re: How to get autoconf to respect CC="gcc -std=c89"?

On Wed, Oct 11, 2023, at 3:43 AM, Niels Möller wrote: > Niels Möller writes: > >> Updated patch below. > > How do we move this forward? I think we first need to settle the > user-visible part, i.e., how AC_C_STANDARD_VERSION should work ... > Latest patch aims for the following, which seems

Re: [PATCH] m4: Update invocation of AC_PROG_LEX

On Wed, Aug 16, 2023, at 2:38 AM, Łukasz Stelmach wrote: > Commit 73f1be5e42e3 to autoconf has introduced an argument to > AC_PROG_LEX. Invocation without the argument has been treated as > obsolete since then. This should go to automake-patches, not autoconf-patches. Also, you should update the

Re: patchset v2: remove remaining internal uses of AC_EGREP_{CPP, HEADER}

On Mon, Apr 3, 2023, at 12:53 AM, Paul Eggert wrote: > Thanks, I took a quick look at all the patches and see no issues. These have been pushed now (actually, yesterday). zr

patchset v2: remove remaining internal uses of AC_EGREP_{CPP,HEADER}

' branch on savannah <https://git.savannah.gnu.org/cgit/autoconf.git/log/?h=zack/no-internal-egrep-cpp> . zwFrom a7dc6d83c7d12b8409c512c3c10ad29f01e6c164 Mon Sep 17 00:00:00 2001 From: Zack Weinberg Date: Sun, 2 Apr 2023 21:54:31 -0400 Subject: [PATCH 3/4] Fold AC_C_STRINGIZE into AC_PROG_CC

Re: RFC PATCH: Overhaul AC_TYPE_GETGROUPS and AC_FUNC_GETGROUPS.

On Sun, Apr 2, 2023, at 5:36 PM, Paul Eggert wrote: > That error case is not very important, since programs are not likely > to exercise it. The really serious failures are for long-dead systems > (Ultrix 4.3, NextSTEP 3.2) that we no longer need to worry about. > > AC_FUNC_GETGROUPS has been

RFC PATCH: Overhaul AC_TYPE_GETGROUPS and AC_FUNC_GETGROUPS.

exercised on a modern system. zwFrom 2182b63d82838d88a41425a4fd4f346715754e8e Mon Sep 17 00:00:00 2001 From: Zack Weinberg Date: Sun, 2 Apr 2023 15:07:58 -0400 Subject: [PATCH] Overhaul AC_TYPE_GETGROUPS and AC_FUNC_GETGROUPS. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer

[committed] Remove two internal uses of AC_EGREP_CPP

is fragile and should generally be avoided. zw From dcf9bb7e3b12f3bd74edff60e80b53e668159579 Mon Sep 17 00:00:00 2001 From: Zack Weinberg Date: Sun, 2 Apr 2023 10:27:08 -0400 Subject: [PATCH 1/2] AC_XENIX_DIR: Rewrite using AC_CANONICAL_HOST. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8

Re: time for Autoconf 2.72 (was: On time64 and Large File Support)

On Mon, Feb 6, 2023, at 12:34 PM, Marko Lindqvist wrote: > On Mon, 6 Feb 2023 at 19:23, Zack Weinberg wrote: >> __ >> On the subject of Debian, we could probably get an RC into experimental and >> ask for archive rebuilds and say that we were hoping to get 2.72 approved >

Re: time for Autoconf 2.72 (was: On time64 and Large File Support)

se, I can then rebuild Fedora packages using > the tarball from the tester list and do some kind of A/B testing. > > Fred. > > On Fri, Feb 3, 2023 at 6:50 AM Sam James wrote: >> >> >> > On 2 Feb 2023, at 23:17, Zack Weinberg wrote: >> > >> >

Re: time for Autoconf 2.72 (was: On time64 and Large File Support)

Due to a series of crises with my day job, the earliest I can promise to do _anything_ Autoconf related is early March. If you have time to make a release before then, please do not wait for me. zw

Re: On time64 and Large File Support

On Sun, 25 Dec 2022 14:19:11 -0500, Paul Eggert wrote: > I reviewed your patch and had the following thoughts. > > * Gnulib doesn't need AC_SYS_LARGEFILE_REQUIRED or > AC_SYS_YEAR2038_REQUIRED and they're easy for users to do on their own > with a simple AS_IF, so let's omit these variants for

Re: [Update install instruction for macOS] Update install instruction for macOS

On Sun, Nov 20, 2022, at 11:43 AM, Paul Eggert wrote: > On 2022-11-20 08:19, Minsoo Choo wrote: >> I tried many methods to solve this, and when I installed perl from source, >> the problem was solved. > > Sure, but this sounds like a routine Perl installation problem, one that > can occur on many

Re: On time64 and Large File Support

On Tue, Nov 15, 2022, at 2:02 PM, Nick Bowler wrote: > But neither suggestion makes any difference. Timestamps seem OK; it > appears that make is deciding to aclocal.m4 (and then configure) because > of prerequisites that do not exist outright: > > % make -d > [...] >Considering

Re: On time64 and Large File Support

On Tue, Nov 15, 2022, at 12:49 PM, Nick Bowler wrote: > On 2022-11-13, Zack Weinberg wrote: >> I have not pushed this, and have only tested it lightly on a current Linux. >> It needs testing on weird old systems, particularly old AIX, HP-UX, MinGW. > > I'd be happy to give it

Re: On time64 and Large File Support

On Sat, Nov 12, 2022, at 4:33 PM, Zack Weinberg wrote: > On Sat, Nov 12, 2022, at 4:31 PM, Paul Eggert wrote: >> Because of the concerns raised in this thread it's become clear that >> what's in Autoconf now is too drastic, and I've proposed (though not yet >>

[committed] More fixes for compilers that reject K function definitions.

This fixes all of the remaining failures exposed by running the testsuite with GCC 12 and CC='cc -Wimplicit-function-declaration -Wold-style-definition -Wimplicit-int -Werror' . * lib/autoconf/c.m4 (_AC_C_C89_TEST_GLOBALS): Don’t use K function definitions. * lib/autoconf/specific.m4

Re: [PATCH] bootstrap: reject m4 versions only older than 1.4.8

On 2022-10-06 11:18 AM, Ozkan Sezer wrote: On 10/6/22, Paul Eggert wrote: Thanks for mentioning the problem. I think the code is right here and the documentation is wrong, so I installed the attached instead. The git history says that the requirement is 1.4.8 or newer:

Re: [PATCH v2] specify void prototype for functions with no parameters

On Thu, Sep 1, 2022, at 7:18 PM, Paul Eggert wrote: > Thanks for checking. How about the attached patch instead? It's closer > to what you originally suggested. > > Zack, any thoughts on this sort of thing? ... > --- a/doc/autoconf.texi > +++ b/doc/autoconf.texi > @@ -5460,9 +5460,8 @@ the

Re: [PATCH 2/2] AC_SYS_LARGEFILE now widens time_t if possible

On Tue, Aug 9, 2022, at 2:07 PM, Paul Eggert wrote: > This change is taken from Gnulib, and is needed for apps like GDB. I'm not _objecting_ to this change but I think it might be nice if the manual explained why AC_SYS_LARGEFILE should do this, instead of having it be solely AC_SYS_YEAR2038's

Re: [PATCH] specify void prototype for functions with no parameters

On Wed, Aug 17, 2022, at 12:51 PM, Khem Raj wrote: > Compilers defaulting to C99 flag such functions as warning which fails > to compile when using -Werror Let's keep the discussion of whether we should make this change at all to the other thread, but also I have some line-by-line feedback for

Re: Problems building rsync with Clang 15 beta

On Thu, Aug 18, 2022, at 12:51 PM, Paul Eggert wrote: > On 8/18/22 09:38, Khem Raj wrote: >> I think the autoconf patch should be good on its own merits regardless > > It partly depends on how much we care about compatibility. Putting the > 'void' in there will break pre-C89 compilers, as well as

Re: [PATCH 1/5] Require Perl 5.10.0 or later.

On Tue, Jul 12, 2022, at 10:06 AM, Eric Blake wrote: > On Sun, Jul 10, 2022 at 03:08:57PM -0400, Zack Weinberg wrote: >> +# That is, AClocal_PATH_PROG_GLOBS_FEATURE_CHECK([PERL], [perl-*]) will >> +# test each program named something like 'perl-*' found anywhere on the &

[PATCH 4/5] Make help-extract.pl work with Perl 5.10.x.

The main issue was use of s///r; the /r modifier was added in 5.14. Since the baseline is now 5.10.0 instead of 5.6.0, a couple places can be tidied up using slightly newer constructs. * help-extract.pl: Use File::Spec::Functions instead of File::Spec for reduced clunkiness.

[PATCH 2/5] make fetch

Our local patches to lib/Autom4te/FileUtils.pm and maint.mk were manually reapplied. --- GNUmakefile |2 +- build-aux/announce-gen | 114 ++- build-aux/config.guess | 1262 -- build-aux/config.sub | 94 ++-

[PATCH 1/5] Require Perl 5.10.0 or later.

6,7 @@ # Written by Zack Weinberg. +use 5.010; use strict; use warnings; diff --git a/configure.ac b/configure.ac index 9362ddf3..3d849ac4 100644 --- a/configure.ac +++ b/configure.ac @@ -153,14 +153,7 @@ AM_MISSING_PROG([HELP2MAN], [help2man]) ## -- ## # We use an absolute name for perl

[PATCH 5/5] Fix testsuite failures on Darwin (aka macOS).

Tests of AC_{CHECK_,}HEADER_STDBOOL were failing on Darwin for two reasons: an m4 quoting bug in tests/local.at causing Darwin sed to throw syntax errors, and an excessively precise interpretation of how C99 and C++11 interact. The latter is worth mentioning in NEWS. * tests/local.at

[PATCH 3/5] Remove ancient backward compatibility code from m4/m4.m4.

We have had AC_PREREQ([2.69]) in our own configure.ac since 2021, and before that it was AC_PREREQ([2.62]) since 2012, so backcompat code for 2.61 is not necessary anymore. Also add logging of the name of each candidate executable and bump the serial number. --- m4/m4.m4 | 13 +++-- 1

[PATCH 0/5] Five mostly unrelated patches

investigating some of the NetBSD failures. Zack Weinberg (5): Require Perl 5.10.0 or later. make fetch Remove ancient backward compatibility code from m4/m4.m4. Make help-extract.pl work with Perl 5.10.x. Fix testsuite failures on Darwin (aka macOS). GNUmakefile

Re: [GNU Autoconf 2.71] testsuite: 10 11 12 14 37 92 236 238 239 240 293 299 397 430 431 432 433 434 435 436 437 438 439 440 509 514 failed

nt. `index` (renamed `m4_index` for namespace cleanliness) is used in dozens of places in autoconf's code, so if the testsuite passes with the bug present, it's only by dumb luck. zw From fec8a33d87bbe9f024a31a18642618716b7ad7c9 Mon Sep 17 00:00:00 2001 From: Zack Weinberg Date: Wed, 6 Jul 2022 16:1

Re: [PATCH] add new AC_PROG_AR helper

On Tue, Jan 25, 2022, at 12:58 AM, Mike Frysinger wrote: > On 24 Jan 2022 09:35, Zack Weinberg wrote: >> Sorry about that, I thought you would merge it yourself (do you not have >> commit access for autoconf?) It's merged now. I had to add a change to >> tests/local.at

Re: [PATCH] add new AC_PROG_AR helper

On Wed, Jan 19, 2022, at 12:22 AM, Mike Frysinger wrote: > On 22 Feb 2021 11:26, Zack Weinberg wrote: >> On Mon, Feb 22, 2021 at 11:15 AM Mike Frysinger wrote: >> > This mirrors the existing RANLIB and related toolchain macros that >> > autoconf already exports

Re: [PATCH 0/3] RFC: automated bootstrap script

On Sat, Feb 6, 2021, at 11:23 AM, Jim Meyering wrote: > On Fri, Feb 5, 2021 at 7:42 AM Zack Weinberg wrote: > > The procedure for building Autoconf from a git checkout is a little > > awkward, involving building it once, then using the just-built > > autoconf to regenerate

Re: [PATCH v4] Fortran Cray pointer macro support

On Mon, Aug 16, 2021, at 10:12 AM, Marshall Ward wrote: > I haven't received any feedback on these updated PRs, which address > the issues raised in the first version. Unfortunately, I have almost no time for Autoconf work until 2022 at the earliest, and what time I do have is already earmarked

Re: [PATCH] lib/autoconf/c.m4: fix NULL pointer dereference in _AC_LANG_IO_PROGRAM

On Mon, Jun 28, 2021 at 10:17 AM Nicolas Iooss wrote: > * lib/autoconf/c.m4: return an error when f is NULL. > --- > lib/autoconf/c.m4 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4 > index 9f881f0bc10c..0d9efa62d450 100644 > ---

Re: [PATCH] add new AC_PROG_AR helper

On Mon, Feb 22, 2021 at 11:15 AM Mike Frysinger wrote: > This mirrors the existing RANLIB and related toolchain macros that > autoconf already exports. Some projects assume `ar` is available > which isn't always safe, so provide a macro that probes the full > toolchain settings. > > This also

[PATCH 0/3] RFC: automated bootstrap script

how to generate M4sh scripts, so I’m posting this for comments and will wait one week before proceeding. (I think the code changes are desirable for other reasons, but the bootstrap process is why I did them now.) Zack Weinberg (3): Generate version.m4 from config.status, in lib/ not lib/m4sugar

[PATCH 2/3] Rewrite bin/autoconf in Perl.

Of all the installed programs (autoconf, autoheader, autom4te, autoreconf, autoscan, autoupdate, ifnames) autoconf is the only one that is a shell script instead of a Perl script. This means it has to do a lot of fiddly quoting and requoting to assemble an autom4te command line, it doesn’t get to

[PATCH 1/3] Generate version.m4 from config.status, in lib/ not lib/m4sugar/.

This simplifies the Makefile a bit and also paves the way for a bootstrap script (replacing the process of re-running autoreconf with the just-built autoconf) which will be able to cope with generated files that get installed in @pkgdatadir@ but not in @pkgdatadir@/m4sugar. * lib/version.in: New

[PATCH 3/3] Add a bootstrap script like Automake has.

The bootstrap script generates the same files ‘autoreconf -vi’ would, in a normal package, but it uses autoconf *from the git sources* to do it. This means people building from git do not need autoconf to be installed already. More importantly, it eliminates the extra steps when building from

Re: [PATCH] doc: Document another portability problem of 'od'.

On Mon, Dec 28, 2020 at 9:43 PM Bruno Haible wrote: > Here's a patch to mention a portability problems of 'od', that I noticed > during Gnulib work. Merged, thank you.

Re: [PATCH v2] general: support CONFIG_SITE being a list of entries

On Wed, Nov 11, 2020 at 11:04 AM Ross Burton wrote: > > Instead of treating CONFIG_SITE as a single path, treat it as a > space-separated list of paths and load them in order. Merged with minor adjustments as 996f608165814d578bdcb0ab2f3382edb8918690, thank you again. zw

Re: [PATCH] general: support CONFIG_SITE being a list of entries

On Wed, Nov 11, 2020 at 8:33 AM Ross Burton wrote: > > Instead of treating CONFIG_SITE as a single path, treat it as a > space-separated list of paths and load them in order. Thanks. This is simple enough that I don't see any reason not to merge it for 2.70, but could you also update the

RFC: Autotest: add official way to execute code before all/each test.

is available from the zack/autotest-new-hooks branch on savannah git. zw From ff49cfa697466da3bbce6b740c228fe84831c174 Mon Sep 17 00:00:00 2001 From: Zack Weinberg Date: Wed, 28 Oct 2020 17:04:22 -0400 Subject: [PATCH] Autotest: add official way to execute code before all/each test. MIME-Version: 1.0

[PATCH 2/2] Improve handling of missing aux scripts (autoreconf)

Make ‘autoreconf --install’ add config.sub, config.guess, and install-sh to the source tree when necessary. This is only relevant for packages that don’t use Automake, because ‘automake --add-missing’ already adds these scripts to the source tree, but apparently there are plenty of packages out

Re: [PATCH] general.m4: fix AC_INIT with unquoted bug-report field

On Tue, Oct 13, 2020 at 3:55 PM Ross Burton wrote: > > The bug report field is passed unquoted to m4_define which causes > problems if it contains values such as ',' (as seen in gmp). > > Ensure that the value is correctly quoted to solve this. Thanks for the patch. FYI, before committing it I

Re: AS_IF

On Mon, Oct 12, 2020 at 3:01 AM Paul Eggert wrote: > On 10/6/20 5:52 PM, Zack Weinberg wrote: > > I'm not sure we should say AS_IF/CASE > > are equivalent to plain shell if/case inside an AC_DEFUN; they do do > > more than just make the m4 expansion stack not be empty. >

[PATCH 1/2 COMMITTED] Fix regressions when using the C++ compiler to perform tests.

The Debian project has done an archive rebuild using autoconf 2.69c, which found several serious regressions from 2.69 where test programs used to be accepted by a C++ compiler, but are now rejected. Part of the problem is that newer C++ compilers are more likely to reject “traditional” sloppy C,

[PATCH 2/2 RFC] Improve handling of missing aux scripts.

Another regression identified by the Debian archive rebuild was that more macros require the presence of config.sub and config.guess now. ‘autoreconf --install’ doesn’t install these itself, it relies on ‘automake --add-missing’ to do that; so, packages that don’t use Automake will fail at the

Re: AS_IF

On Tue, Oct 6, 2020 at 5:57 PM Bruno Haible wrote: > Paul Eggert wrote in > : > > > AFAICS, this is relevant for code written directly into configure.ac. But > > > inside an AC_DEFUN it is irrelevant, because required macros are

Re: [PATCH] Fortran Cray pointer macro support

On Tue, Oct 6, 2020 at 12:24 PM Marshall Ward wrote: > This patch adds a macro, AC_FC_CRAY_POINTER, which tests if the Fortran > compiler supports Cray pointers. This seems like a reasonable addition to me. Would anyone with Fortran experience care to comment? I have never properly learned

[RFC PATCH 2/3] Use WARNINGS=none to suppress warnings from autom4te runs.

aclocal uses autom4te in trace mode to scan configure.ac for macros whose definition is not yet available. It has a kludge to prevent this from producing spurious warnings, but a cleaner, fully backward compatible, way to get the same effect is to set WARNINGS=none in the environment and not pass

[RFC PATCH 1/3] New utility function Automake::ChannelDefs::merge_WARNINGS.

This function merges a list of warnings categories into the environment variable WARNINGS, returning a new value to set it to. The intended use is in code of the form { local $ENV{WARNINGS} = merge_WARNINGS ("this", "that"); # run a command here with WARNINGS=this,that,etc } This is not

[RFC PATCH 0/3] Work around autoconf/automake warnings skew (automake side)

org/archive/html/autoconf-patches/2020-09/msg8.html> for the rationale for merge_WARNINGS, which is not used in automake, but will be in autoconf. Zack Weinberg (3): New utility function Automake::ChannelDefs::merge_WARNINGS. Use WARNINGS=none to suppress warnings from autom4te runs.

[RFC PATCH 3/3] Update documentation of warnings options and strictness levels.

The warning categories ‘cross’ and ‘portability-recursive’ were not mentioned in the manual. Also clarify the relationship between warnings categories and strictness levels, and streamline the description of strictness levels by merging the “Gnits” section into the “Strictness” section. *

[RFC PATCH 6/6] Autoupdate AC_{DIAGNOSE, FATAL, OBSOLETE, WARNING} and _AC_COMPUTE_INT.

While working on the previous patches I noticed that all of these macros are officially obsolete, but autoupdate doesn’t replace them. _AC_COMPUTE_INT is easy to autoupdate. AC_{DIAGNOSE,FATAL,WARNING} require a little special handling because their replacements are m4sugar macros, and

[RFC PATCH 1/6] Manually sync ChannelDefs.pm from automake.

ChannelDefs.pm *ought* to be kept in sync between automake and autoconf, because it defines the set of valid -W options, and autoreconf assumes that it can pass arbitrary -W options to all of the tools it invokes. However, it isn’t covered by either project’s ‘make fetch’ and it hasn’t actually

[RFC PATCH 5/6] Update documentation related to warnings.

This makes the Texinfo documentation consistent with the previous changes. --help output regarding warnings is already drawn directly from ChannelDefs.pm and thus does not need to be updated. * doc/autoconf.texi: Update all ‘invocation’ sections to describe -W/--warnings consistently, and to

[RFC PATCH 2/6] New utility function Autom4te::ChannelDefs::merge_WARNINGS.

This function merges a list of warnings categories into the environment variable WARNINGS, returning a new value to set it to. The intended use is in code of the form { local $ENV{WARNINGS} = merge_WARNINGS ("this", "that"); # run a command here with WARNINGS=this,that,etc } This is not

[RFC PATCH 3/6] Disable all warnings when running autoconf as a subprocess.

autoheader and autoscan both run autoconf in trace mode, and autoheader makes a point of passing down the warnings options. This means autoheader prints warnings that a regular invocation of autoconf would also print, so in the common case where both are being run by autoreconf, the warnings are

[RFC PATCH 0/6] Work around autoconf/automake warnings skew

ill do that in a separate commit after all the dust settles from this patchset. zw -- Zack Weinberg (6): Manually sync ChannelDefs.pm from automake. New utility function Autom4te::ChannelDefs::merge_WARNINGS. Disable all warnings when running autoconf as a subprocess. Use WARNINGS to pass down warnings o

Re: doc: Mention two more shell portability problems

I verified both of these behaviors and merged the patch, with two slight changes to the text: - it is specifically Solaris 10 /bin/sh that executes redirected compound commands in a subshell; ksh (aka /usr/xpg4/bin/sh) doesn't. - the latest version of dash also doesn't support file descriptors

Re: [PATCH] Swallow m4traces that have no file/line number

I would like to get this bug fixed for autoconf 2.70, but the trouble is I have no idea how to reproduce the problem on my computer. The various old reports you originally linked to, all seem to involve filesystem-level bugs on MacOS, which I don't have convenient access to, or with archaic

Re: RFC PATCH 1/2] AS_INIT: try to ensure fds 0, 1, 2 are open

On Thu, Aug 27, 2020 at 6:49 PM Paul Eggert wrote: > > On 8/27/20 3:20 PM, Zack Weinberg wrote: > > On Thu, Aug 27, 2020 at 2:09 PM Paul Eggert wrote: > >> > >>> + if (exec 3>&0) 2>/dev/null; then :; else exec 0 >>> + if (exec

Re: RFC PATCH 1/2] AS_INIT: try to ensure fds 0, 1, 2 are open

On Thu, Aug 27, 2020 at 2:09 PM Paul Eggert wrote: > > > + if (exec 3>&0) 2>/dev/null; then :; else exec 0 > + if (exec 3>&1) 2>/dev/null; then :; else exec 1>/dev/null; fi > > + if (exec 3>&2); then :; else exec 2>/dev/null; fi > > This is all _AS_ENSURE_STANDARD_FDS needs to do;

[RFC PATCH 2/2] _AS_ENSURE_STANDARD_FDS: use lsof and fstat when possible

This follow-up patch adds additional ways of detecting whether fds 0, 1, 2 are closed, using the ‘lsof’ and ‘fstat’ utilities. The former is not a standard component of any OS, but is very widely installed and can produce machine-parseable output; the latter ships with many BSD variants but its

[RFC PATCH 1/2] AS_INIT: try to ensure fds 0, 1, 2 are open

A patch was recently proposed for GNU libc to make *all* processes start up with file descriptors 0, 1, and 2 guaranteed to be open. Part of the rationale for this patch was that configure scripts fail catastrophically if these fds are closed, even if you just want to run --help or --version, e.g.

[PATCH] Generate manpages directly from source code.

ion) 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 receive

[PATCH] tests: New helper macro AT_CHECK_MAKE.

This macro factors out some repeated code surrounding tests that run make, such as honoring $MAKE, *not* honoring $MAKEFLAGS, and normalizing the exit status. Partially addresses bug #110267 (problems with Sun’s make barfing on GNU make options from $MAKEFLAGS). Also addresses some unrelated

Re: [RFC PATCH 0/2] Additional AC_INIT/AC_OUTPUT-related diagnostics

On Fri, Aug 14, 2020 at 5:06 PM Paul Eggert wrote: > On 8/14/20 11:44 AM, Zack Weinberg wrote: > > I found a kludge that works, > > but I’d like to hear opinions on whether we should instead postpone > > this patch till after 2.70 so we can coordinate with automak

[PATCH 2/2] Warn if AC_INIT or AC_OUTPUT are missing from configure.ac (#107986)

It is almost always incorrect for a configure script to omit either AC_INIT or AC_OUTPUT. Issue warnings in the ‘syntax’ category for this. The implementation is, unfortunately, a bit of a kludge. To check for the _absence_ of a macro invocation, we can use m4_provide_if inside a m4_wrap hook.

[PATCH 1/2] Trim whitespace from arguments of AC_INIT (#107986)

Specifically, all five arguments, if present, are passed through m4_normalize before doing anything else with them. For instance, AC_INIT([ GNU Hello ], [1.0]) is now equivalent to AC_INIT([GNU Hello], [1.0]). As a consequence, newlines in the arguments to AC_INIT are now converted to spaces

[RFC PATCH 0/2] Additional AC_INIT/AC_OUTPUT-related diagnostics

to hear opinions on whether we should instead postpone this patch till after 2.70 so we can coordinate with automake on the addition of the missing autom4te feature. zw Zack Weinberg (2): Trim whitespace from arguments of AC_INIT (#107986) Warn if AC_INIT or AC_OUTPUT are missing from

Re: [PATCH] AC_LANG_INT_SAVE: Modernize function declarators (C89 and above).

On Wed, Aug 5, 2020 at 1:32 PM Vincent Lefevre wrote: > > On 2020-08-05 07:24:38 -0700, Paul Eggert wrote: > > On 8/5/20 3:59 AM, Vincent Lefevre wrote: > > > This allows one to avoid a failure with AC_COMPUTE_INT when using > > > the -Werror=old-style-definition GCC option. > > > > Why is this

Re: [PATCH] Revert 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)'

On Thu, Jul 16, 2020 at 8:50 PM Paul Eggert wrote: > On 7/16/20 11:40 AM, Zack Weinberg wrote: > > I believe that what's in trunk now should work fine for > > cross-compilation of programs that don't require yywrap > > I thought so too, but after eyeballing the trunk a

Re: [PATCH] Revert 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)'

On Thu, Jul 16, 2020 at 2:47 PM Ross Burton wrote: > On Thu, 16 Jul 2020 at 19:41, Zack Weinberg wrote: > > Can we slow down a bit please? I had written out a patch (basically > > equivalent to what's now in trunk) and I am in the process of setting > > up a cross-co

Re: [PATCH] Revert 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)'

On Thu, Jul 16, 2020 at 1:55 PM Ross Burton wrote: > On Thu, 16 Jul 2020 at 18:51, Paul Eggert wrote: >> >> On 7/16/20 10:34 AM, Ross Burton wrote: >> > Wouldn't that break cross-compilation where a host flex is present but >> > target libfl isn't? That case worked previously and should work

  1   2   >