Eric Blake wrote:
> With the proposal for autoconf 2.64, it can be
> either invoked or required, in any order, without warning; it guarantees
> that the expansion only occurs once; and it will never suffer from
> out-of-order expansion (thanks to the embedded require under the hood).
Sounds perfec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 1/23/2009 4:26 PM:
> I find this m4_defun_once interesting too: it incorporates the workaround
> that we previously used in gnulib.
>
> But before you jump to the conclusion that AC_DEFUN_IDEMPOTENT is not
> needed any mor
Eric Blake wrote:
> > m4_define([m4_defun_once], [dnl
> > m4_defun([_$0_$1], [$2])dnl
> > m4_defun([$1], [m4_require([_$0_$1])])
>
> I like this idea. ... I don't think we need
> AC_DEFUN_IDEMPOTENT; rather, we just make AC_DEFUN_ONCE the single macro
> that is the user's way to declare tha
Hi Jim,
> Once you've adjusted your patch to do the same for the
> new return path it adds, you're welcome to commit it.
Done.
> *ENDPTR is no longer guaranteed to be set.
Whee, well spotted. I missed this most probably because there was no
documentation nearby that would have reminded me of th
FYI, today's addition in gnulib of emit_bug_reporting_address,
broke coreutils builds, as Bob Proulx noted:
http://buildbot.proulx.com:9000/
Here's the fix I've pushed:
>From 016f8c99984d4a6005eef76d204cd2c396b357d0 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Fri, 23 Jan 2009 18:27:36 +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paolo Bonzini on 1/23/2009 5:25 AM:
>>> It's too late for doing that: AC_DEFUN_ONCE was introduced on 2004-10-11.
>> I know.
>>
>>> Besides that, AC_DEFUN_ONCE and AC_DEFUN_IDEMPOTENT have really opposite
>>> semantics. You cannot confuse
Bruno Haible wrote:
> Now, when there is an out-of-memory while c_strtod is called, the handling is
> inconsistent:
> - If it occurs inside newlocale() or inside strtod_l() or inside strtod(),
> the function returns 0 with errno set to ENOMEM.
> - If it occurs inside strdup() of the locale
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paolo Bonzini on 1/23/2009 1:46 AM:
> I don't like this too. Does it work to simply change gl_INIT to
> m4_define?!?
No, because we currently forbid direct calls to AC_REQUIRE at the top
level (although I would like to get rid of that re
Jim Meyering writes:
> Simon Josefsson wrote:
>> l...@gnu.org (Ludovic Courtès) writes:
> ...
>>> Is there any reason this cannot be made part of `version-etc'?
>>
>> No reason. It seems like a better place actually. Jim, how about this
>> patch?
>
> Hi Simon,
>
> That looks fine.
> However, p
Simon Josefsson wrote:
> l...@gnu.org (Ludovic Courtès) writes:
...
>> Is there any reason this cannot be made part of `version-etc'?
>
> No reason. It seems like a better place actually. Jim, how about this
> patch?
Hi Simon,
That looks fine.
However, please make the three changes like this:
>> It's too late for doing that: AC_DEFUN_ONCE was introduced on 2004-10-11.
>
> I know.
>
>> Besides that, AC_DEFUN_ONCE and AC_DEFUN_IDEMPOTENT have really opposite
>> semantics. You cannot confuse people more than by using the same name for
>> two entities with opposite semantics.
>
> It loo
Bruno Haible wrote:
> Paolo Bonzini wrote:
>>> - macros defined with AC_DEFUN_IDEMPOTENT are *known* to be expandable
>>> any number of times, hence they may be both invoked and required,
>>>
>>> - macros defined with AC_DEFUN_ONCE are *known* to be expandable only
>>> once, hence the r
"Stefan Monnier" writes:
+ printf (_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT);
> [...]
>> However, as far as I know there isn't a gnulib translation domain that
>> is automatically used for messages in gnulib code when you import it to
>> a project. So the strings above will end up
Paolo Bonzini wrote:
> > - macros defined with AC_DEFUN_IDEMPOTENT are *known* to be expandable
> > any number of times, hence they may be both invoked and required,
> >
> > - macros defined with AC_DEFUN_ONCE are *known* to be expandable only
> > once, hence the recommendation for the
Hi Eric,
> > But no, I don't want to
> > think about AC_REQUIRE's bug every time I want to invoke an autoconf macro!
>
> My argument is that if Autoconf can enforce rules, such as refusing to
> compile if you try to expand instead of require an AC_DEFUN_ONCE macro,
> then it is easy to fix your c
> configure.ac:50: warning: AC_REQUIRE: `gl_MULTIARCH' was expanded before it
> was
> required
> m4/printf.m4:811: gl_PRINTF_ENOMEM is expanded from...
> m4/vasprintf-posix.m4:7: gl_FUNC_VASPRINTF_POSIX is expanded from...
> m4/gnulib-comp.m4:45: gl_INIT is expanded from...
> configure.ac:50: th
> - macros defined with AC_DEFUN_IDEMPOTENT are *known* to be expandable
> any number of times, hence they may be both invoked and required,
>
> - macros defined with AC_DEFUN_ONCE are *known* to be expandable only
> once, hence the recommendation for them is to AC_REQUIRE them,
Do w
Karl Berry ha escrit:
> However, as far as I know there isn't a gnulib translation domain that
>
> There actually is, although I admit I don't know how the messages get
> integrated into the gnulib-using packages:
> http://translationproject.org/domain/gnulib.html
It is a "compendium" domai
18 matches
Mail list logo
