Re: new snapshot available: autoconf-2.72c

On Tue, Mar 28, 2023 at 7:23 AM Richard Purdie wrote: > I was able to work around the EGREP_TRADITIONAL issue by reordering > macros. The issue is conditional code blocks which mean > EGREP_TRADITIONAL was not set in some configure option combinations > leading to obtuse failures. > > Our testing

Re: new snapshot available: autoconf-2.72c

On Mon, Mar 27, 2023 at 2:49 PM Václav Haisman wrote: > On 27. 03. 23 17:38, Jim Meyering wrote: > > We're overdue for a new release, so here's a snapshot in preparation > > for that, which I want to call 2.73 (skipping 2.72). There has never > > been an autoconf-2.72 relea

Re: new snapshot available: autoconf-2.72c

On Mon, Mar 27, 2023 at 10:18 AM Zack Weinberg wrote: > On Mon, Mar 27, 2023, at 11:38 AM, Jim Meyering wrote: > > We're overdue for a new release, so here's a snapshot in preparation > > for that, which I want to call 2.73 (skipping 2.72). There has never > > been an autoc

new snapshot available: autoconf-2.72c

ensure autoconf-latest.* links stay up-to-date maint: advertise GNU in README tests: typo fix Jim Meyering (5): fix a typo tests: avoid test failures due to new EGREP_TRADITIONAL AC_FUNC_ALLOCA: fix a misplaced (now fatal) closing "fi" build: run &qu

snapshot preparations

ass for me on Fedora 37 x86_64. >From 0b92bd72ca6cae6190ee6b6c95449e4243597e75 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 25 Mar 2023 22:07:19 -0700 Subject: [PATCH 1/2] build: run "make fetch", which updated these: Preparing to make a pre-release snapshot, update these: *

Re: new snapshot available: grep-3.9.4-c83f

On Tue, Mar 21, 2023 at 1:50 PM Bruno Haible wrote: > Jim Meyering wrote: > > this snapshot really was built with > > the very latest autoconf from master. Compare with grep-3.9, which > > was bootstrapped using a version of autoconf from October. > > ... >

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

On Fri, Mar 17, 2023 at 7:52 PM Paul Eggert wrote: > On 3/17/23 19:08, Jim Meyering wrote: > > Can someone see if there's some small/safe set of changes that are > > essential? > > If none (or few/easy), I might have time to make a snapshot soon. > > As far as I know,

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

On Fri, Mar 17, 2023 at 6:00 PM Paul Eggert wrote: > On 3/17/23 16:47, Sam James wrote: > > Clang 16 was released today. Unfortunately, all released versions of > > autoconf still generate configure scripts which are incompatible with it. > > Presumably "./configure CC='clang -std=gnu17" is a

Re: the cost of due diligence

On Tue, Jun 28, 2022 at 4:31 PM Paul Eggert wrote: > Thanks for fixing that old bug of mine. I installed the attached further > patch to refactor and simplify. If I'd done it this way originally the > bug wouldn't have existed. Nice. Thanks for that improvement. One other thing I noticed along

the cost of due diligence

configure script that uses AC_FUNC_ACLOCAL, but there was no test coverage of that macro. One could argue that this lack of testing was another issue. I've pushed these: >From 615e34cbe3e74dad5aef4b4e0525dea5cf72220d Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sun, 26 Jun 2022 15:37:51 -0

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

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 the configure script in the source directory, > then throwing away the entire first

Re: Hidden files in autoconf 2.70 distribution?

On Wed, Dec 9, 2020 at 3:49 PM Paul Eggert wrote: > On 12/9/20 7:46 AM, Bruno Haible wrote: > > It comes from Gnulib's git-version-gen and GNUmakefile. > > > > I'm not defending it. In fact, it annoys me. But I didn't spend the > > time to find another way to record the release version. > >

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

On Sat, May 9, 2020 at 8:05 PM Harald van Dijk wrote: > On 10/05/2020 02:10, Karl Berry wrote: > > +Although we would like to remove this function from Automake, since it's > > +not used, that would break older versions of Autoconf, which seems > > +gratuitious. So we leave it, unchanged. > >

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

On Sat, May 9, 2020 at 6:10 PM Karl Berry wrote: > > Probably best to leave it, as is, and mark it as known-to-be-unused at > least via comment. > > How does the text below look for an explanation? Very good! Thanks for dealing with this. Two suggestions below. > (By the way, I noticed

Re: [PATCH] up_to_date_p: treat equal mtime as outdated.

On Mon, Apr 20, 2020 at 6:13 PM Karl Berry wrote: > the command that updates autom4te.cache/traces.0 does not modify > configure.ac at the same time. > > No argument for that specific case. But looking at the change in > isolation: > > - if ($mtime < mtime ($dep)) > + if ($mtime

Re: minor regression: config header templates

On Sat, Mar 14, 2020 at 10:15 PM Jim Meyering wrote: > When testing the latest automake with autoconf-2.69, all of automake's > tests pass. But with the latest autoconf (built from master) in my > path, two tests "FAIL", as below. I bisected to v2.69-181-g78ad1

minor regression: config header templates

When testing the latest automake with autoconf-2.69, all of automake's tests pass. But with the latest autoconf (built from master) in my path, two tests "FAIL", as below. I bisected to v2.69-181-g78ad1b0b, aka https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=v2.69-181-g78ad1b0b I plan

[PATCH] doc/autoconf.texi: fix spelling/grammar nits

I made some minor documentation improvements more than a year ago, but had never shared them. I've just pushed this: >From b8fd7ae75637970a7102358be737c7e8558f9e1b Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 23 Nov 2017 06:58:38 -0800 Subject: [PATCH] doc/autoconf.texi: fix spell

FYI: updated copyright dates for 2.17

I've just pushed this all-mechanical commit, so that "make syntax-check" continues to pass: maint: update copyright dates for 2017 * all files: Run "make update-copyright". * doc/autoconf.texi: Update manually. [actual patch omitted] ___

Re: [PATCH] doc: detail inconsistencies in sed word boundary handling

On Sun, Oct 30, 2016 at 12:01 PM, Pádraig Brady wrote: > * doc/autoconf.texi (Limitations of usual tools): Display a > table showing where the various syntaxes for word boundaries > are supported. ... > +Portable scripts should be aware of the inconsistencies and > +options

Re: bug#17471: On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

On Sun, May 11, 2014 at 1:48 PM, Paul Eggert egg...@cs.ucla.edu wrote: Following up to the grep snapshot announcement in: http://lists.gnu.org/archive/html/platform-testers/2014-05/msg0.html That snapshot failed to build the shell scripts egrep and fgrep properly on Solaris 10, because

Re: bug#17471: On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

On Sun, May 11, 2014 at 1:48 PM, Paul Eggert egg...@cs.ucla.edu wrote: Following up to the grep snapshot announcement in: http://lists.gnu.org/archive/html/platform-testers/2014-05/msg0.html That snapshot failed to build the shell scripts egrep and fgrep properly on Solaris 10, because

Re: bug#17471: On Solaris 10, grep snapshot apparently hit by bleeding-edge Autoconf bug

Thanks for dealing with that. The only potential problem I see with your patch would be when one runs configure with a perverse program name transformation, e.g., --program-transform-name='s/^/$/', introducing a shell metacharacter (or leading/trailing white space!) in the resulting name. In that

Re: Future autoconf package compression

Jeffrey Walton wrote: On Sat, Dec 15, 2012 at 9:35 PM, Jim Meyering j...@meyering.net wrote: Paul Eggert wrote: On 12/15/2012 05:54 PM, Jim Meyering wrote: FYI, a couple of weeks ago, Aki Helin exposed still more problems in gzip's unpacking code. Well, to be fair, I also have a similar

Re: Future autoconf package compression

Jim Meyering wrote: Bob Friesenhahn wrote: On Sat, 24 Nov 2012, Marko Lindqvist wrote: On 2 March 2012 06:45, Eric Blake ebl...@redhat.com wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you, and you need the .gz or .bz2 release

Re: Future autoconf package compression

Paul Eggert wrote: On 12/15/2012 05:54 PM, Jim Meyering wrote: FYI, a couple of weeks ago, Aki Helin exposed still more problems in gzip's unpacking code. Well, to be fair, I also have a similar problem with 'tar' in my inbox, from Aki, but I'm not inclined to suggest that we stop using

Re: Future autoconf package compression

Marko Lindqvist wrote: On 2 March 2012 06:45, Eric Blake ebl...@redhat.com wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you, and you need the .gz or .bz2 release, please speak up now. I just encountered new argument for

Re: Future autoconf package compression

Bob Friesenhahn wrote: On Sat, 24 Nov 2012, Marko Lindqvist wrote: On 2 March 2012 06:45, Eric Blake ebl...@redhat.com wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you, and you need the .gz or .bz2 release, please speak up now.

FYI: grep had to switch: AC_PROG_CC_STDC - AC_PROG_CC

with exit status: 1 ./bootstrap: autoreconf failed I worked around it by making this change. From 703a9cf560db57abfc9ff3457fc5a696c1f563ac Mon Sep 17 00:00:00 2001 From: Jim Meyering j...@meyering.net Date: Wed, 24 Oct 2012 11:00:14 +0200 Subject: [PATCH] build: use AC_PROG_CC_STDC rather than

Re: [PATCH] AC_PROG_CC_C11: new macro, which AC_PROG_CC_STDC now defaults to

Paul Eggert wrote: ... Yes, on further thought I'm inclined to agree. Also, it's a lot simpler. Also, it fixes Jim's bug. There's a lot to like. Please see the patch below, which I've pushed. Further comments welcome. From f7fe375b26f39d0a6624ad9a6c532d9361a3226b Mon Sep 17 00:00:00 2001

Re: [PATCH] AC_PROG_CC_C11: new macro, which AC_PROG_CC_STDC now defaults to

Paul Eggert wrote: ... Yes, on further thought I'm inclined to agree. Also, it's a lot simpler. Also, it fixes Jim's bug. There's a lot to like. Please see the patch below, which I've pushed. Further comments welcome. From f7fe375b26f39d0a6624ad9a6c532d9361a3226b Mon Sep 17 00:00:00 2001

Re: [PATCH] scripts: quote `like this', not 'like this'

Stefano Lattarini wrote: As per updated GCS recommendations. * bin/autoconf.as, bin/autoreconf.in, bin/autoscan.in, ifnames.in, bin/autoupdate.in: Throughout these files. * bin/autoheader.in, bin/autom4te.in: Likewise. Also, remove some useless escaping of the ' single-quote characters, and

Re: [PATCH] AC_PROG_CC_C11: new macro, which AC_PROG_CC_STDC now defaults to

Paul Eggert wrote: I pushed this. I did only C11, not C++11, since I'm not a C++ guru. * NEWS: * doc/autoconf.texi (C Compiler): Document this. (Gnulib, Function Portability, Particular Functions) (Header Portability, Particular Headers, Defining Symbols) (Printing Messages, Limitations

Re: [PATCH] maint: avoid new syntax-check failure

Eric Blake wrote: On 07/22/2012 02:51 PM, Jim Meyering wrote: I suggest to update maint.mk soon to the latest from gnulib, mainly for its new check for the CVE-2012-3386 (make distcheck) bug. Once you do that, you see a new make syntax-check failure, triggered by this example from

[PATCH] maint: avoid new syntax-check failure

!HAVE_DECL_MALLOC void *malloc (size_t *s); #endif @end example Here's a fix for that that should be pushed first. This probably counts as trivial, but I'll wait for an ACK. From 32d938eaa7e1cb756997a665cb1669ef6dca3110 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sun, 22 Jul

Re: [PATCH] tests: use configure.ac, not configure.in, with aclocal/automake involved

Stefano Lattarini wrote: Do so because future automake and aclocal versions (starting from 1.13) won't support 'configure.in' anymore as the name of the Autoconf input file. Without this patch, the Autoconf testsuite experience some spurious failures when run with the development version of

Re: [PATCH] tests: use configure.ac, not configure.in, with aclocal/automake involved

Stefano Lattarini wrote: On 07/21/2012 05:51 PM, Jim Meyering wrote: Stefano Lattarini wrote: Do so because future automake and aclocal versions (starting from 1.13) won't support 'configure.in' anymore as the name of the Autoconf input file. Without this patch, the Autoconf testsuite

[PATCH] maint: fix typos in old ChangeLog files

FYI, From b29e5e79d5203400c4366c61d998bd9cdf30ef0d Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Tue, 29 May 2012 12:33:46 +0200 Subject: [PATCH] maint: fix typos in old ChangeLog files Culprits identified and fixed automatically using these commands: git ls-files

[PATCH] maint: avoid make syntax-check failure

I was surprised to find that make syntax-check was failing. Here's the trivial fix: (I'll push it later today) From eaa96cb8bd6dca5317329b6682df91dfda286d06 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Wed, 11 Apr 2012 12:05:38 +0200 Subject: [PATCH] maint: avoid make

Re: Why I am happy to dump gzip for xz

Mike Frysinger wrote: On Tuesday 06 March 2012 04:57:27 Jim Meyering wrote: Why I am happy to dump gzip for xz: - xz decompresses more quickly is that true ? i thought last i looked, they were close, but gzip was consistently slightly faster. maybe if the bottleneck is more I/O than CPU

Re: Autoconf distributions and xz dependency

Bob Friesenhahn wrote: This reply should have been sent to the autoconf list rather than directly to Eric. The below is what I sent to Eric: On Thu, 1 Mar 2012, Eric Blake wrote: The Autoconf team is considering releasing only .xz files for 2.69; if this would be a hardship for you, and

Re: Autoconf distributions and xz dependency

Bob Friesenhahn wrote: On Fri, 2 Mar 2012, Jim Meyering wrote: If you can demonstrate a portability problem, please provide details. From what I've heard (distributing xz-only compressed tarballs of coreutils, grep, diffutils, parted, etc.) there have been no problems building xz from source

Re: Autoconf distributions and xz dependency

Jim Meyering wrote: Bob Friesenhahn wrote: On Fri, 2 Mar 2012, Bob Friesenhahn wrote: I tried to test how much peak memory 'xz' uses to decompress the autoconf tarball but was (apparently) defeated by the strange way that 'xz' is linked. I will try again with a different tool this weekend

Re: Autoconf distributions and xz dependency

Bob Friesenhahn wrote: On Fri, 2 Mar 2012, Jim Meyering wrote: It does not successfully build using GCC on my Solaris 10 system, and not even with the workaround described in the INSTALL file. Did you report it? Yes. Since it involves Solaris' ld, it's harder to reproduce and work around

[PATCH] maint: avoid make syntax-check failure

FYI, From a1a00a9768e6206feb8ca768d2aa66cdf3408c5c Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sat, 28 Jan 2012 15:19:38 +0100 Subject: [PATCH] maint: avoid make syntax-check failure * Makefile.am ($(srcdir)/INSTALL): Remove spurious space-before-TAB. --- Makefile.am

Re: [PATCH 4/7] maint: placate syntax-check rules: exempt some false positives

Eric Blake wrote: ... Subject: [PATCH] maint: convert .x-sc_* into exclude_file_name_regexp--sc_* exemptions Many of the .x-sc_* exemptions were no long necessary. Remove those files and instead, provide exemptions via variable definitions in cfg.mk to address the few remaining exceptions.

Re: [PATCH] INSTALL: convert to '' quoting, drop blank line at end

Eric Blake wrote: This is allowed by recent GNU Coding Standards changes, and mirrors recent gnulib changes: https://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00267.html https://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00298.html I've confirmed that after these changes, the

[PATCH 7/7] maint: fix or disable failing syntax-check rules

From: Jim Meyering meyer...@redhat.com * cfg.mk (local-checks-to-skip): List failing tests, so we skip them, for now. (old_NEWS_hash): Update. (exclude_file_name_regexp--sc_file_system): Exempt doc/autoconf.texi for it's uses of Filesystem Hierarchy Standard. --- cfg.mk | 16

[PATCH 3/7] maint: tweak to avoid triggering space-tab-prohibiting syntax-check

From: Jim Meyering meyer...@redhat.com * tests/m4sh.at (nargs): Use TAB-SP, not SP-TAB in abusive file name, to avoid triggering the space-tab-prohibiting syntax-check. --- tests/m4sh.at |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/m4sh.at b/tests/m4sh.at

[PATCH 1/7] doc: fix grammar/doubled-word errors

From: Jim Meyering meyer...@redhat.com * doc/autoconf.texi: Remove/fix doubled-word errors. Also, s/can not/cannot/. * lib/m4sugar/m4sh.m4: Reword if IF comment to avoid triggering the doubled-word warning. --- doc/autoconf.texi |8 lib/m4sugar/m4sh.m4 |2 +- 2 files changed

[PATCH 6/7] maint: also sync maint.mk and useless-if-before-free from gnulib

From: Jim Meyering meyer...@redhat.com * cfg.mk (gnulib-update): Add them to the list. * maint.mk: Update from gnulib. * build-aux/gitlog-to-changelog: Likewise. * build-aux/useless-if-before-free: New file, from gnulib. --- build-aux/gitlog-to-changelog| 24 +++-- build-aux/useless

update maint.mk; fix syntax-check failures

I noticed that autoconf's maint.mk was out of date wrt gnulib's, so updated it. Also, even before the update, make syntax-check was failing numerous tests. With the update, even more (added tests) rules were failing. With this series, I've addressed some of the issues and arranged to skip the

[PATCH 2/7] maint: remove empty lines at EOF

From: Jim Meyering meyer...@redhat.com * man/autoconf.x: Remove empty line at EOF. * man/autoheader.x: Likewise. * man/autoscan.x: Likewise. * man/autoupdate.x: Likewise. * man/ifnames.x: Likewise. * tests/compile.at: Likewise. * doc/fdl.texi: Likewise. --- doc/fdl.texi |1 - man

Re: [PATCH 2/7] maint: remove empty lines at EOF

Eric Blake wrote: On 01/21/2012 04:14 AM, Jim Meyering wrote: From: Jim Meyering meyer...@redhat.com * man/autoconf.x: Remove empty line at EOF. * man/autoheader.x: Likewise. * man/autoscan.x: Likewise. * man/autoupdate.x: Likewise. * man/ifnames.x: Likewise. * tests/compile.at: Likewise

Re: [PATCH 5/7] maint.mk: update from gnulib

Eric Blake wrote: On 01/21/2012 04:14 AM, Jim Meyering wrote: From: Jim Meyering meyer...@redhat.com No ChangeLog? Thanks. That was an oversight. Added. --- maint.mk | 1526 +++--- 1 files changed, 1172 insertions(+), 354

Re: [PATCH 4/7] maint: placate syntax-check rules: exempt some false positives

Eric Blake wrote: On 01/21/2012 04:14 AM, Jim Meyering wrote: From: Jim Meyering meyer...@redhat.com No ChangeLog entry? Added, now. * cfg.mk: Exempt maint.mk from the undesirable word seq check. Exempt maint.mk and autoconf.texi from the test_minus_ao check. --- cfg.mk |4

Re: [PATCH 7/7] maint: fix or disable failing syntax-check rules

Eric Blake wrote: On 01/21/2012 04:14 AM, Jim Meyering wrote: From: Jim Meyering meyer...@redhat.com * cfg.mk (local-checks-to-skip): List failing tests, so we skip them, for now. (old_NEWS_hash): Update. (exclude_file_name_regexp--sc_file_system): Exempt doc/autoconf.texi for it's uses

Re: [PATCH 4/7] maint: placate syntax-check rules: exempt some false positives

Jim Meyering wrote: Eric Blake wrote: ... Incomplete. I'd rather see this patch nuke all of the .x-sc files and convert them into exclude_file_name_regexp entries. That will be an improvement, but it does not belong in this series. This series is addressing preexisting (and a few new

[PATCH] maint: remove ChangeLog from version control; now we generate it

:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Tue, 17 Jan 2012 11:18:08 +0100 Subject: [PATCH] maint: remove ChangeLog from version control; now we generate it Instead, generate it from git commit logs and insert it into each distribution tarball. * Makefile.am (EXTRA_DIST): Add ChangeLog

[PATCH] tests: avoid spurious failure for each gnu-fortran-using test

Surprised to see all fortran-running tests fail, I investigated... From 905b85a2060f600dbc21e262262f77c8074f7db1 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Tue, 17 Jan 2012 12:22:59 +0100 Subject: [PATCH] tests: avoid spurious failure for each gnu-fortran-using test

Re: [PATCH] maint: generate ChangeLog from git log

Stefano Lattarini wrote: Following the practice set by various other GNU projects, we start to automatically generate the ChangeLog file from the git commit messages. This will avoid duplication (as the ChangeLog entries were always inserted both in the git commit message and in the

[PATCH] avoid new warning about undefined $ARGV[0]

Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sun, 15 Jan 2012 17:16:52 +0100 Subject: [PATCH] avoid new warning about undefined $ARGV[0] * lib/Autom4te/General.pm (getopt): Avoid warning induced by yesterday's change: $ARGV[0] may not be defined, e.g., when invoked via

Re: [PATCH] avoid new warning about undefined $ARGV[0]

Stefano Lattarini wrote: Hi Jim. On 01/15/2012 05:22 PM, Jim Meyering wrote: Without this change, numerous tests would fail. E.g., on a Fedora 16 system, running autoreconf would print this warning: Use of uninitialized value $ARGV[0] in pattern match (m//) at \ /p/share

Re: [PATCH] avoid new warning about undefined $ARGV[0]

Stefano Lattarini wrote: On 01/15/2012 05:33 PM, Jim Meyering wrote: Stefano Lattarini wrote: Hi Jim. On 01/15/2012 05:22 PM, Jim Meyering wrote: Without this change, numerous tests would fail. E.g., on a Fedora 16 system, running autoreconf would print this warning: Use

Re: [PATCH] avoid new warning about undefined $ARGV[0]

Stefano Lattarini wrote: On 01/15/2012 05:58 PM, Jim Meyering wrote: [SNIP] Stefano Lattarini wrote: Yes, awaiting review. For projects where I only contribute minimally, I want to wait for an explicit ACK before *any* commit, whether bug-fix or not. That's why I'm also waiting

[PATCH] docs: improve the prose describing _AC_CHECK_TYPE_NEW_BODY

FYI, While looking at a config.log file, I noticed a diagnostic that was due to the code below, and found it suspicious enough that I went to read the macro definition. From 7a615729c9c56a3608ec0224a67f21d23ea6b3ad Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sun, 24 Jul

Re: how to query filesystem type?

86d19b44a5357158359e06e5db99cf7608470956 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Tue, 5 Jul 2011 22:49:56 +0200 Subject: [PATCH] stat: recognize GPFS as a file system type * src/stat.c (human_fstype) [S_MAGIC_GPFS]: Add a case, to handle GPFS_SUPER_MAGIC/0x47504653. Prompted

Re: bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed

Stefano Lattarini wrote: On Tuesday 14 June 2011, Jim Meyering wrote: Here's what I expect to do for coreutils, along with an advice-update for gnulib's init.sh: Thanks, I'll apply something similar to automake `tests/defs' soonish. I have a doubt below, tough (see near the end). From

Re: bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed

Eric Blake wrote: On 06/13/2011 04:11 AM, Jim Meyering wrote: Thank you for the testing and report. That bad file number error comes from this code in init.sh: : ${stderr_fileno_=2} warn_ () { echo $@ 1$stderr_fileno_; } Because of that, the log contains less information than usual

Re: bug#8846: coreutils-8.12 on HP-UX 11.31: 3 of 365 tests failed

Eric Blake wrote: On 06/13/2011 07:36 AM, Jim Meyering wrote: However, it looks like using eval didn't help at all. What does this do on that system? sh -c 'e=2; warn_ () { echo $@ 1$e; }; warn_ x' $ sh -c 'e=2; warn_ () { echo $@ 1$e; }; warn_ x' x This is what happens via tests

[PATCH] README-hacking: fix typo

Here's a tiny fix: From 5941d6d14017f0bcf638b6d61dbb9374f81c3e6f Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Sat, 26 Mar 2011 21:50:43 +0100 Subject: [PATCH] README-hacking: fix typo * README-hacking: s/just build/just built/. --- ChangeLog |5 + README

Re: bug in autoconf-2.64

Ralf Wildenhues wrote: [ this is http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/7834 from http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01480.html adding bug-gnulib; followups can elide bug-autoconf ] * Ralf Wildenhues wrote on Thu, Feb 24, 2011 at 07:24:35AM CET: IOW, it

Re: bug in autoconf-2.64

Jim Meyering wrote: Ralf Wildenhues wrote: [ this is http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/7834 from http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01480.html adding bug-gnulib; followups can elide bug-autoconf ] * Ralf Wildenhues wrote on Thu, Feb 24, 2011 at 07:24

Re: sed --posix does not catch incomplete arguments

Eric Blake wrote: On 06/18/2010 05:27 AM, Bruno Haible wrote: Hi Eric, About the only portable alternative that I could think of for a makefile would be to use multiple echo (or printf) into a temporary file, then use sed -f file, rather than relying on multiple -e. The makefile can also

Re: AC_CHECK_LIB not finding my library

Eric Blake wrote: On 04/19/2010 10:00 AM, Joel J. Adamson wrote: Does this portion of the manual already contain enough hints in that direction? If not, are you willing to help provide some wording to add to the manual?

Re: portability of 'printf' command

Karl Berry wrote: And the reason that I would _like_ to have printf(1) added to the list of portable tools is because of the number of non-portable shell scripts that are currently using 'echo -n', which is doomed to failure in some shells, instead of printf because printf was

Re: portability of 'printf' command

Bob Friesenhahn wrote: On Wed, 7 Apr 2010, Karl Berry wrote: In any event, I suspect that anyone using such an ancient system *and* installing a brand-new version of package foo that uses printf in its autoconfery would also have installed coreutils (or at least sh-utils), and therefore will

Re: Incorrect use of USE_XATTR in coreutils-8.4

[Cc'd autoconf for a suggestion below] Pádraig Brady wrote: On 18/01/10 10:32, Pádraig Brady wrote: On 17/01/10 08:03, Jim Meyering wrote: Thanks! That would fix it, but please retain the 0/1 semantics, in case we ever want to use USE_XATTR in a C (as opposed to cpp) expression. # Map yes

Re: Incorrect use of USE_XATTR in coreutils-8.4

Eric Blake wrote: According to Jim Meyering on 1/22/2010 6:17 AM: However, it'd sure be nice to use something more generic than lib/config.h. IMHO, autoconf should make configure AC_SUBST its currently-internal-only CONFIG_HEADERS variable. While we wait, I suppose we can kludge

Re: [PATCH] tests: don't silently skip the sort-version tests

Eric Blake wrote: According to Jim Meyering on 1/13/2010 2:26 AM: The behavior of bash via /bin/sh (same for zsh and dash, though without the warning) is probably POSIX-conforming, but this example illustrates why it would be better to emulate openBSD's /bin/sh. * tests/misc/sort-version

[PATCH] AC_INIT: Use correct value for PACKAGE_TARNAME

configure PACKAGE_TARNAME='-autoconf-' ... But how did that get there? Surprised there's no test that notices the failure? I was. I haven't dug into the origin but did write a patch and add a test: From b2c8ce3b7a00bfd2af297f8882882fa8e50cc803 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer

Re: [PATCH 2/5] New FAQ node: Debugging.

Ralf Wildenhues wrote: ... +...@node Debugging +...@section Debugging @command{configure} scripts Nice tips! I've proposed an addition to one of your lists and made a few very subjective style suggestions: +While in general, @command{configure} scripts generated by Autoconf +strive to be

Re: three tiny doc-only patches

Eric Blake wrote: According to Jim Meyering on 6/6/2009 9:49 AM: I found an old branch with these on it. Any objection or suggestion? $ $[0] AUTOTEST_PATH=bin -possibly amounts into +is equivalent to this, when run from /tmp/foo-1.0: - PATH=/tmp/foo-1.0/bin:/src/foo-1.0/bin:\$PATH

Re: three tiny doc-only patches

Eric Blake wrote: According to Jim Meyering on 6/6/2009 10:47 AM: Thanks for the quick feedback. How about this: -directories relatively to the top level of this distribution. E.g., +directories relative to the top level of this distribution. E.g., +invoking this from within build

Re: git repository out of date

Ralf Wildenhues wrote: * Romain Lenglet wrote on Fri, Jun 05, 2009 at 01:53:09PM CEST: Can somebody please update the Git repository on Savannah, for both Autoconf and Automake, as they seem to have restored from the latest backup which was dated from May 21st (Autoconf) and May 24th

[PATCH] Fix syntax errors in autoconf.texi.

:00 2001 From: Jim Meyering meyer...@redhat.com Date: Thu, 28 May 2009 19:08:20 +0200 Subject: [PATCH] Fix syntax errors in autoconf.texi. * doc/autoconf.texi (Erlang Libraries): @-escape curly braces in example code. --- ChangeLog |6 ++ doc/autoconf.texi | 10 +- 2 files

Re: improve INSTALL contents

Alfred M. Szmidt wrote: can you please also read, and follow http://lists.gnu.org/archive/html/autoconf/2009-05/msg00058.html? I'm sure you must have missed it because I failed to spam it to three mailing lists. But your repetitions are just as boring as those from everyone

Re: test fails when no C++ compiler is available

Ralf Wildenhues wrote: [ dropping bug-automake, adding autoconf-patches ] Hi Jim, Eric, * Jim Meyering wrote on Tue, May 12, 2009 at 11:30:40AM CEST: I've just built automake-from-git on a newly-installed system that lacked a C++ compiler. It failed like this: 220. compile.at:204: 220

Re: test fails when no C++ compiler is available

Ralf Wildenhues wrote: [ dropping bug-automake, adding autoconf-patches ] Hi Jim, Eric, * Jim Meyering wrote on Tue, May 12, 2009 at 11:30:40AM CEST: I've just built automake-from-git on a newly-installed system that lacked a C++ compiler. It failed like this: 220. compile.at:204: 220

Re: test fails when no C++ compiler is available

Jim Meyering wrote: Hi Ralf, Whoops. This is for autoconf, but for automake. I've just built automake-from-git on a newly-installed system that lacked a C++ compiler. It failed like this: 220: Multiple languages FAILED (compile.at:249) ... 220. compile.at

[PATCH] * lib/m4sugar/m4sh.m4: fix grammar: s/are/is/ = there is no indirection

Barely worth mentioning... I'll wait a couple of hours before pushing. (and I will add the ChangeLog entry) From e329d5af15adb18b3143f75654fe9f73f411e9e0 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Mon, 18 Aug 2008 11:08:14 +0200 Subject: [PATCH] * lib/m4sugar/m4sh.m4

Re: Bug in autoconf 2.62 with old GNU awk

Ralf Wildenhues ralf.wildenh...@gmx.de wrote: [ moving from bug-autoconf ] ... Thank you for the bug report. I think this is a coreutils bug or two. configure is working as intended in substituting a multiline value (Autoconf supports multiline values since a couple of years), but the

AC_HEADER_ASSERT: don't say assertions are disabled when they're not

of AS_IF. If no one objects, I'll push in a few hours: [gnulib's gl_ASSERT will get a similar change, included below] From 27d44bf831cdf696049e2d6a96173d8ea0fa40eb Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Wed, 10 Dec 2008 14:45:35 +0100 Subject: [PATCH] AC_HEADER_ASSERT

Re: getgroups: test: =: unary operator expected

Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 10/22/2008 9:32 AM: To autoconf folks, I've attached the obvious patch below, and will push it some time tomorrow if no one objects. * lib/autoconf/functions.m4 (AC_FUNC_GETGROUPS): Always define the shell variable

Re: getgroups: test: =: unary operator expected

Eric Blake [EMAIL PROTECTED] wrote: Jim Meyering jim at meyering.net writes: To autoconf folks, I've attached the obvious patch below, and will push it some time tomorrow if no one objects. From: Jim Meyering meyering at redhat.com Date: Wed, 22 Oct 2008 17:25:46 +0200 Subject: [PATCH

Re: getgroups: test: =: unary operator expected

Jim Meyering. dnl A wrapper around AC_FUNC_GETGROUPS. -# Copyright (C) 1996, 1997, 1999, 2000, 2001, 2002, 2003, 2004 Free +# Copyright (C) 1996, 1997, 1999, 2000, 2001, 2002, 2003, 2004, 2008 Free # Software Foundation, Inc. # # This file is free software; the Free Software Foundation

Re: [PATCH] posix-shell.m4: reject Solaris 11's /bin/sh (due to umask)

Peter O'Gorman [EMAIL PROTECTED] wrote: Eric Blake wrote: According to Jim Meyering on 9/16/2008 3:58 AM: Jim Meyering [EMAIL PROTECTED] wrote: I discovered that Solaris 11's /bin/sh exhibits the following surprising behavior: $ /bin/sh -c 'umask 22; (umask 0); umask' We

Re: interrupt causes parse error in configure script

Ralf Wildenhues [EMAIL PROTECTED] wrote: * Jim Meyering wrote on Mon, Aug 18, 2008 at 11:57:45PM CEST: Ralf Wildenhues [EMAIL PROTECTED] wrote: I think we can factor it into a simpler testcase. I just tried this: $ sh -c 'if test `sleep 5; echo hi` = hi ; then echo yes; fi' and found

interrupt causes parse error in configure script

trap code also fails to run. Comments, suggestions ? From a1c0ac7453b663d6886c96970dbf3161f0046c0c Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Sun, 15 Jun 2008 17:56:37 +0200 Subject: [PATCH] AC_VAR_YES: new function, to handle an unusual failure Prompted

Re: interrupt causes parse error in configure script

Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Jim, * Jim Meyering wrote on Mon, Aug 18, 2008 at 11:23:01AM CEST: I admit that this not a big deal, but even when I interrupt a configure script, I prefer to see it die cleanly. Otherwise, I have to wonder if some clean-up trap code also fails

  1   2   3   >