Re: bug#8878: 24.0.50; ./configure: line 17305: test: =: unary operator expected

On 06/16/11 14:45, Glenn Morris wrote: > This looks like a gnulib bug (in lstat.m4) to me. Thanks, fixed in gnulib as follows, with the fix propagated to the Emacs trunk as bzr 104611. ChangeLog |7 +++ m4/lstat.m4 |4 ++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --

Re: [PATCH 0/348] move AC_LIBOBJ invocations to the module descriptions

Tom G. Christensen wrote: > a bootstrap with all modules is now broken. > > These modules contain references to a deleted m4 file: > crypto/gc-arcfour:m4/arcfour.m4 > crypto/gc-des:m4/des.m4 > crypto/gc-hmac-md5:m4/hmac-md5.m4 > crypto/gc-hmac-sha1:m4/hmac-sha1.m4 > crypto/gc-rijndael:m4/rijndael.

Re: config.h double inclusion

Alfred M. Szmidt wrote: > I think that autoconf should have the guard for double inclusion. Autoconf does not need to provide a double-inclusion guard for config.h, because those packages that need it can get it through use of AH_TOP and AH_BOTTOM. Bruno -- In memoriam Imre Nagy

Re: config.h double inclusion

> I'm thinking that maybe should be generated with a double > inclusion guard But the general rule is that must always be included first, no? So there shouldn't ever be a possibility of including it twice. Right, which is the case in inetutils in all places where we use . The p

Re: bug#8881: config.h double inclusion

>> I'm thinking that maybe should be generated with a double >> inclusion guard > > But the general rule is that must always be included first, no? > So there shouldn't ever be a possibility of including it twice. > > It might be better to have config.h do something like this

fprintftime dependencies

Hi Jim, The module 'fprintftime' depends on module 'strftime' - as if a function nstrftime() was necessary to implement fprintftime(). But actually the fprintftime() implementation invokes strftime(), not nstrftime(). Here's a proprosed fix for this unneeded dependency: 2011-06-16 Bruno Haible

Re: config.h double inclusion

On 06/16/11 10:36, Alfred M. Szmidt wrote: > I'm thinking that maybe should be generated with a double > inclusion guard But the general rule is that must always be included first, no? So there shouldn't ever be a possibility of including it twice. It might be better to have config.h do somethi

Re: [PATCH 0/348] move AC_LIBOBJ invocations to the module descriptions

On 06/16/2011 12:12 AM, Bruno Haible wrote: I wrote: Please review and comment. I'll wait for objections for a week. The week is over. I have now pushed the series of patches, after doing an additional test with --create-megatestdir. Something went wrong because a bootstrap with all modules

config.h double inclusion

Hey, in inetutils we have a problem of where sometimes is included twice, but gnulib redefines a macro that was already specified in , for example gnulib:lib/argp.h: #include -- #define HAVE_DECL_PROGRAM_INVOCATION_NAME 0 #define GNULIB_PROGRAM_INVOCATION_NAME 1 ... #include --

Re: [PATCH 0/348] move AC_LIBOBJ invocations to the module descriptions

Jim Meyering wrote: > it complains about the following: > > m4/fprintftime.m4: AC_LIBOBJ([fprintftime]) > Do not use AC_LIBOBJ in m4/*.m4; > see I missed this one. Fixed: 2011-06-16 Bruno Haible fprintftime: Mo

Re: Dealing with character ranges in grep

Hi. > From: Jim Meyering > To: Bruno Haible > Cc: Paolo Bonzini , Aharon Robbins , > bug-gnulib@gnu.org, bug-grep , k...@freefriends.org > Subject: Re: Dealing with character ranges in grep > Date: Thu, 16 Jun 2011 07:58:05 +0200 > > To make this proposed change go through, that configur

Re: [PATCH 0/348] move AC_LIBOBJ invocations to the module descriptions

Jim Meyering wrote: > it complains about the following: > >     m4/stdio-safer.m4:  AC_LIBOBJ([tmpfile-safer]) >     Do not use AC_LIBOBJ in m4/*.m4; This file ought to have been removed. Fixed: 2011-06-16 Bruno Haible tmpfile-safer: Finish 2011-05-23 commit. * m4/stdio-safe

Re: [PATCH 0/348] move AC_LIBOBJ invocations to the module descriptions

Jim Meyering wrote: > it complains about the following: > >     m4/printf-posix-rpl.m4:  AC_LIBOBJ([printf]) >     Do not use AC_LIBOBJ in m4/*.m4; This one was a typo in my mail. Fixed: 2011-06-16 Bruno Haible syntax-check: Fix typo. * Makefile (allow_AC_LIBOBJ): Mention pri

Re: Dealing with character ranges in grep

Hi All. > Date: Wed, 15 Jun 2011 14:09:45 -0600 > From: Eric Blake > To: Paul Eggert > CC: Aharon Robbins , bonz...@gnu.org, bug-g...@gnu.org, > bug-gnulib@gnu.org, k...@freefriends.org > Subject: Re: Dealing with character ranges in grep > > > Doesn't this issue also arise for file name

Re: proposal: make [A-Z] range handling locale-independent

Philipp Thomas wrote: > * Jim Meyering (j...@meyering.net) [20110616 11:57]: > >> In some locales, the [A-Z] regexp currently matches 25 of the >> lower case letters. For example, >> >> $ echo a| LC_ALL=cs_CZ grep '[A-Z]' >> a >> $

Re: Dealing with character ranges in grep

* Jim Meyering (j...@meyering.net) [20110616 10:55]: > For the record, at least Fedora's grep and sed both build > --without-included-regex, so would be affected. SLES and openSUSE also build sed and grep --without-included-regex, so would also be affected. Philipp

Re: Dealing with character ranges in grep

Hello, On Jun 16 15:51 Stanislav Brabec wrote: Johannes Meixner wrote: Again: I do not care if this or that special feature is supported or not because I think that consistent behaviour has topmost priority. Do you prefer "consistent behavior of regexp in all applications across the whole d

Re: proposal: make [A-Z] range handling locale-independent

* Jim Meyering (j...@meyering.net) [20110616 11:57]: > In some locales, the [A-Z] regexp currently matches 25 of the > lower case letters. For example, > > $ echo a| LC_ALL=cs_CZ grep '[A-Z]' > a > $ echo y| LC_ALL=cs_CZ grep '[A-Z]' > y

Re: Dealing with character ranges in grep

Johannes Meixner wrote: > Again: > I do not care if this or that special feature is supported or not > because I think that consistent behaviour has topmost priority. Do you prefer "consistent behavior of regexp in all applications across the whole distribution" or "consistent behavior of (GNU) g

Re: Dealing with character ranges in grep

Jim Meyering wrote: > Johannes Meixner wrote: > > recently I became openSUSE package maintainer for grep and gawk. > > > > I added Stanislav Brabec, openSUSE package maintainer for sed. > > > > In short: > > I support and appreciate everything which leads to consistence. > .. > > Thanks for the qu

Re: Dealing with character ranges in grep

Hello, On Jun 16 13:51 Stanislav Brabec wrote (excerpt): grep in openSUSE uses glibc regex by default. Yes. Currently grep in openSUSE is built using "configure --without-included-regex" as it was built for openSUSE all the time. Perhaps there is a misunderstanding what I mean. What I mea

Re: Dealing with character ranges in grep

Hello, recently I became openSUSE package maintainer for grep and gawk. I added Stanislav Brabec, openSUSE package maintainer for sed. In short: I support and appreciate everything which leads to consistence. On Jun 16 07:58 Jim Meyering wrote: Jim Meyering wrote: Bruno Haible wrote: Pao

proposal: make [A-Z] range handling locale-independent

Jim Meyering wrote: > Jim Meyering wrote: >> Bruno Haible wrote: >>> Paolo, >>> > [=e=] to match "e" as well as accented versions like é, è and ê). > That is the one feature that you get with glibc, and that you would > sacrifice when building --with-included-regex. I agree

Re: Dealing with character ranges in grep

Jim Meyering wrote: ... >> Thus, if we go this route, we are effectively saying >> that people who want self-consistent regex-handling >> in our tools must build with --with-included-regex or end >> up causing subtle problems. >> >> That's a big leap. >> I'm not saying I won't take upstream grep ov

Re: Dealing with character ranges in grep

Johannes Meixner wrote: > recently I became openSUSE package maintainer for grep and gawk. > > I added Stanislav Brabec, openSUSE package maintainer for sed. > > In short: > I support and appreciate everything which leads to consistence. ... Thanks for the quick reply and the support.