Re: portability of xargs

Dan Kegel wrote: Meson is a candidate for such a next-gen config system. It is in python, which does not quite qualify as usable during early uplift/bootstrap, but there are C ports in progress, see e.g. https://sr.ht/~lattis/muon/ *Please* do not introduce a dependency on Python; they do n

Re: [bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is not available

[expanding CC list to cover later message] Paul Eggert wrote: On 2023-02-07 21:29, Jacob Bachmeyer wrote: use Exporter; -use Time::HiRes qw(stat); use IO::File; +# use sub-second resolution timestamps if available, +# carry on with one-second resolution timestamps if that is all we have

Re: [bug#61240] [PATCH 2/2] Gracefully degrade if Time::HiRes is not available

onf portable to older Perl, and if Jacob Bachmeyer or some other Perl expert can vouch for the change, we might as well put it in. I have since checked and it appears that the same patch I submitted for Automake on this bug should also work for Autoconf, appl

Re: Which Perl versions Autoconf needs

Paul Eggert wrote: On 2023-03-29 16:32, Jacob Bachmeyer wrote: Is there anything more needed from me to get similar fixes into Autoconf? I started to do that, by installing this: https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=e2220ed33e69d8bc6504e3f6279894afe33a99a5 into

Re: Which Perl versions Autoconf needs [PATCH included]

Paul Eggert wrote: On 2023-03-29 16:32, Jacob Bachmeyer wrote: Is there anything more needed from me to get similar fixes into Autoconf? I started to do that, by installing this: https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=e2220ed33e69d8bc6504e3f6279894afe33a99a5 into

Re: Which Perl versions Autoconf needs [PATCH included]

Nick Bowler wrote: On 2023-03-30, Zack Weinberg wrote: [...] Because I don't think anyone else currently active in development has either the time or the expertise for it. (Just as a data point here, the oldest version of Perl that I myself have any access to, presently, is 5.*16*, and I do

Re: Which Perl versions Autoconf needs

Gavin Smith wrote: On Wed, Mar 29, 2023 at 09:29:30PM -0500, Jacob Bachmeyer wrote: Do we need a direct configure test for "has Perl module"? AC_PERL_MODULE([Digest::SHA]) would need to execute `$PERL -e "require Digest::SHA"` and consider Digest::SHA available if that re

Re: Which Perl versions Autoconf needs [PATCH included]

Paul Eggert wrote: On 2023-03-30 06:06, Zack Weinberg wrote: Are you, Jacob Bachmeyer, volunteering to maintain the Perl scripts in autoconf and automake, for at least the next several years, and in particular to test compatibility with these very old versions of Perl? Although testing

Re: Which Perl versions Autoconf needs [PATCH included]

Paul Eggert wrote: On 2023-03-30 12:40, Jacob Bachmeyer wrote: The closest I have seen so far was the use of the regex \K escape in build-aux/help-extract.pl, except that the tool in question only needs to be run by Autoconf maintainers because its outputs are included in release tarballs

Re: rhel8 test failure confirmation? [PATCH for problem affecting Automake testsuite]

A quick introduction to the situation for the Autoconf list: The Automake maintainers have encountered a bizarre issue with sporadic random test failures, seemingly due to "disk writes not taking effect" (as Karl Berry mentioned when starting the thread). Bogdan appears to have traced the iss

Re: remaining tasks before Autoconf release

Bruno Haible wrote: [...] * In the other cases - 32-bit OS, or Perhaps this has already been addressed, but what prevents a 32-bit OS from nonetheless having a 64-bit time_t? Do the tests accommodate the possibility of time_t being long long? They should: there is no reason to ex

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

Niels Möller wrote: Paul Eggert writes: This doesn't let you say "I want either c89 or c99, but not c11". That's right, I tried only the very simplest thing. Providing a list makes sense, thoguh. What should the interface be? AC_C_STANDARD_VERSION([c99 c89]) looks reasonable to m

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

Niels Möller wrote: [...] Jacob Bachmeyer writes: Niels Möller wrote: AC_C_STANDARD_VERSION([c89 c99]) is a bit meaningless; if compiler has c89, that's what will be used, and if it doesn't have c89, it won't have c99 either. Free compilers may behave that

AT_MTIME_DELAY not working? (was: Re: [platform-testers] autoconf-2.72e released [release candidate])

Zack Weinberg wrote: On Thu, Dec 21, 2023, at 3:27 AM, Frederic Berat wrote: On Wed, Dec 20, 2023 at 10:22 PM Zack Weinberg wrote: I also get this one that fails once in a while (3 failures out of 12 executions): 11: autoconf: forbidden tokens, basic FAILED (tools.at:481) So

Re: Is it safe to use ax_gcc_builtin to detect __builtin_offsetof?

Jeffrey Walton wrote: On Sun, Feb 25, 2024 at 2:09 AM Jeffrey Walton wrote: The page does not list __builtin_offsetof in the list of documented builtins. But the page says "Unsupported built-ins will be tested with an empty

Re: C23 support in Autoconf

Paul Eggert wrote: On 2024-04-30 12:03, Zack Weinberg wrote: Another reason to want this type of control is if you are deliberately trying to ensure that your code continues to compile with old compilers. While we're adding to our wishlist that should also be a configure-time option, not mer