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
th
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 fo
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 l
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 mi
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 propos
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 va
Hello Derek,
thank you very much for taking care about this.
On Mon, Jun 06, 2005 at 02:31:24PM -0400, Derek Price wrote:
> 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 obj
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
__
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
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 t
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 `m4_
Bruno Haible wrote:
>>- use m4_pushdef/m4_popdef instead of define/undefine
>>- use AS_TR_* instead of raw m4_translit
>>
>>
>
>m4_pushdef, m4_popdef, AS_TR_* are not documented in the autoconf manual
>(latest release, 2.59). In consequence, their meaning can change, or they
>can go away entir
On Fri, Jun 03, 2005 at 05:54:29PM +0200, Bruno Haible wrote:
> James Youngman wrote:
> > HAVE_MINMAX_IN_FOO_H is defined if MIN is defined in foo.h and MAX is
> > not.
>
> Have you seen a system where this is the case?
No, never.
> The autoconf test assumes that when MIN is defined in a heade
Stepan Kasal wrote:
> I read your macro in minmax.m4. I'd like to propose some
> changes in style:
> - avoid the obsoleted AC_TRY_COMPILE
AC_TRY_COMPILE is shorter and more mnemonic than the *_IFELSE macros.
> - use m4_pushdef/m4_popdef instead of define/undefine
> - use AS_TR_* instead of raw m
James Youngman wrote:
> HAVE_MINMAX_IN_FOO_H is defined if MIN is defined in foo.h and MAX is
> not.
Have you seen a system where this is the case? The autoconf test assumes
that when MIN is defined in a header, MAX will be defined as well, and
vice versa.
Bruno
___
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
> +AC_DEFINE([HAVE_MIN
Hi Bruno,
I read your macro in minmax.m4. I'd like to propose some
changes in style:
- avoid the obsoleted AC_TRY_COMPILE
- use m4_pushdef/m4_popdef instead of define/undefine
- use AS_TR_* instead of raw m4_translit
A patch with my proposal is attached; it's not tested, sorry.
Could you please
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bruno Haible wrote:
>I therefore commit this patch.
Thanks, Bruno. Thank, Paul.
Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCkeZjLD1OTBfyMaQRAgmpAKDl
Paul Eggert wrote:
> Second, suppose and have conflicting
> definitions of MIN and MAX? To work around the latter potential
> problem you can #undef MIN and MAX after including .
In this case we'll still get warnings, either when the user does
#include
#include
or when he does
#in
Derek Price wrote:
> >First, the $gl_* variables should be cached, with AC_CACHE_CHECK.
>
> Done.
Thanks.
> + AC_CACHE_CHECK([whether defines MIN & MAX],
> + gl_limits_h_has_minmax,
Cache variables need to have _cv_ in their name. So one needs to change this
to gl_cv_limits_h_ha
The latest patch looks reasonable to me. Bruno, you're the minmax
maintainer: can you please take a look at it?
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Paul Eggert wrote:
>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.
>
>
Done.
>Second, suppose and have conflicting
>
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 and have conflicting
definitions of MIN and MAX? To work around the latter po
Paul Eggert wrote:
>Derek Price <[EMAIL PROTECTED]> writes:
>
>
>
>
>>+#ifdef LIMITS_H_HAS_MINMAX
>>+# include
>>+#elif SYS_PARAM_H_HAS_MINMAX
>>+# include
>>+#endif
>>
>>
>
>This doesn't work if and both define MIN.
>
>
Hrm. Okay, I've fixed this, though I think such a system that i
Derek Price <[EMAIL PROTECTED]> writes:
> +#ifdef LIMITS_H_HAS_MINMAX
> +# include
> +#elif SYS_PARAM_H_HAS_MINMAX
> +# include
> +#endif
This doesn't work if and both define MIN.
> + AC_CHECK_HEADERS_ONCE([sys/param.h],
> +[gl_have_sys_param_h=:], [gl_have_sys_param_h=false])dnl
You
Paul Eggert wrote:
>Derek Price <[EMAIL PROTECTED]> writes:
>
>
>
>>minmax was so nice and small, but would you be willing to add an m4 file
>>which called AC_CHECK_HEADERS([sys/param.h]) and the following lines to
>>the beginning of minmax.h?
>>
>>#ifdef HAVE_SYS_PARAM_H
>># include
>>#endif
>
Derek Price <[EMAIL PROTECTED]> writes:
> minmax was so nice and small, but would you be willing to add an m4 file
> which called AC_CHECK_HEADERS([sys/param.h]) and the following lines to
> the beginning of minmax.h?
>
> #ifdef HAVE_SYS_PARAM_H
> # include
> #endif
Better yet, why not have "con
On Friday, May 13, 2005 at 18:54, Derek Price wrote:
> /usr/include/sys/param.h:222: warning: `MIN' redefined
> /usr/include/sys/param.h:223: warning: `MAX' redefined
[..]
> minmax was so nice and small, but would you be willing to add an m4 file
> which called AC_CHECK_HEADERS([sys/param.h]) and t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I get the following warning on NetBSD 1.6.1 when using the minmax module:
In file included from /usr/include/arpa/inet.h:65,
from socket-client.h:27,
from socket-client.c:20:
/usr/include/sys/param.h:222: warning: `MI
29 matches
Mail list logo
