Re: gcc -Wall warning for minmax.h

2005-06-10 Thread Derek Price
Stepan Kasal wrote: After that fix, we could also remove the AS_LITERAL_IF with m4_fatal. I'm not sure what you were referring to here so I've attached a patch to document AS_LITERAL_IF as you requested a few days ago. I will commit it in a few days if there are no objections. It looks

Re: gcc -Wall warning for minmax.h

2005-06-10 Thread Derek Price
Paul Eggert wrote: I'm not sure about the documentation change. It's not yet clear to me that we want to document AS_LITERAL_IF (the above example being one of the gotchas). If we do want to document it we probably need to be more systematic about it and its friends. So I left that alone for

Re: gcc -Wall warning for minmax.h

2005-06-10 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: + [test ${$1+set} = set], + [{ as_var=$1; eval test \\${$as_var+set}\ = set; }])]) That change looks like it can do only good, so I installed it into Autoconf. Thanks. I'm not sure about the documentation change. It's not yet clear to me that we

FYI: M4 macro documentation (was Re: gcc -Wall warning for minmax.h)

2005-06-08 Thread Derek Price
Derek Price wrote: Would anyone mind if I committed a patch with @msindex entries for the 37 or so undocumented m4_* macros in the `Redefined M4 Macros' node of doc/autoconf.texi? I'm not bothering to include the patch in this email because it is too simple but I don't want to waste the 15

Re: gcc -Wall warning for minmax.h

2005-06-07 Thread Derek Price
Stepan Kasal wrote: - We need to document also AS_LITERAL_IF and m4_fatal (And you could also document m4_warning, when you are at it.) I'll see about it after I get comments on the first round back. - we have to document also the fact that AS_TR_SH AS_TR_CPP expand to literal variable

Re: gcc -Wall warning for minmax.h

2005-06-07 Thread Stepan Kasal
Hi, On Tue, Jun 07, 2005 at 10:19:47AM -0400, Derek Price wrote: - we have to document also the fact that AS_TR_SH AS_TR_CPP expand to literal variable (symbol) name, if their argument is a literal I didn't think this was important from the user's perspective. In the patch I proposed, I

Re: gcc -Wall warning for minmax.h

2005-06-06 Thread Derek Price
Bruno Haible wrote: I blindly searched for m4_pushdef in the manual and didn't find it. (May I suggest that these renamed m4_* macros be added to the manual's index, one by one?) Autoconf folks: Would anyone mind if I committed a patch with @msindex entries for the 37 or so undocumented

Re: gcc -Wall warning for minmax.h

2005-06-06 Thread Derek Price
Bruno Haible wrote: But AS_TR_* is actually undocumented, right? Yes, AS_TR_SH AS_TR_CPP appear to be undocumented. I've submitted a patch to autoconf-patches to remedy this and will commit it within a few days unless there are objections there. Cheers, Derek

[bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-06-04 Thread Stepan Kasal
Hello, On Fri, Jun 03, 2005 at 05:53:00PM +0200, Bruno Haible wrote: AS_TR_* are not documented in the autoconf manual You are right. I have to start by documenting AS_TR_SH, AS_TR_CPP, AS_LITERAL_IF and m4_fatal. Then I can resubmit the patch. AC_TRY_COMPILE is shorter and more mnemonic

Re: [bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-06-03 Thread James Youngman
On Fri, Jun 03, 2005 at 01:54:01PM +0200, Stepan Kasal wrote: +gl_CACHE_VAR, +[AC_COMPILE_IFELSE([#include $1 + int x = MIN (42, 17);], + [gl_CACHE_VAR=yes], + [gl_CACHE_VAR=no])]) + if test $gl_CACHE_VAR = yes; then +

[bug-gnulib] Re: gcc -Wall warning for minmax.h

2005-06-03 Thread Bruno Haible
Derek Price wrote: Actually, `m4_popdef' is documented explicitly in my Autoconf 2.59 manual. The Autoconf 2.59 manual also contains the following text: With a few exceptions, all the M4 native macros are moved in the `m4_' pseudo-namespace, e.g., M4sugar renames `define' as

Re: [bug-gnulib] gcc -Wall warning for minmax.h

2005-05-18 Thread Paul Eggert
Derek Price [EMAIL PROTECTED] writes: Corrected patch attached. Thanks. A couple more things. (Sorry I didn't catch it earlier.) First, the $gl_* variables should be cached, with AC_CACHE_CHECK. Second, suppose limits.h and sys/param.h have conflicting definitions of MIN and MAX? To work

Re: [bug-gnulib] gcc -Wall warning for minmax.h

2005-05-17 Thread Derek Price
Paul Eggert wrote: Derek Price [EMAIL PROTECTED] writes: +#ifdef LIMITS_H_HAS_MINMAX +# include limits.h +#elif SYS_PARAM_H_HAS_MINMAX +# include sys/param.h +#endif This doesn't work if limits.h and sys/param.h both define MIN. Hrm. Okay, I've fixed this, though I think such a