[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: expand-before-require bug
From: |
Eric Blake |
Subject: |
Re: expand-before-require bug |
Date: |
Fri, 23 Jan 2009 08:39:19 -0700 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 |
-----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 people more than by using the same name for
>>> two entities with opposite semantics.
>> It looks to me like, in the wild, AC_DEFUN_ONCE is used for idempotent
>> macros (and in Autoconf too, see AC_CANONICAL_*). The only correct use
>> of AC_DEFUN_ONCE (where the warning *is* desired) is AC_NO_EXECUTABLES;
>> and not even fully correct, as you'd want an error there.
And you can still achieve an error for that case, by writing a
self-modifying macro:
AC_DEFUN([AC_NO_EXECUTABLES],
[first-time defn...
m4_define([AC_NO_EXECUTABLES], [m4_fatal(...)])])
>
> Besides, what's the difference between expanding once only a macro, or
> expanding once only a macro + give a warning?
>
> m4_define([m4_defun_once], [dnl
> m4_defun([_$0_$1], [$2])dnl
> m4_defun([$1], [m4_require([_$0_$1])])
I like this idea. I agree that this proposed definition of AC_DEFUN_ONCE
is sufficient for our needs - it guarantees that a macro is expanded
exactly once, and that the real body is required (and thus hoisted). The
use of AC_DEFUN_ONCE is to guarantee that the macro body is expanded
exactly once. The old semantics merely warned the user if a second
expansion was encountered, but the new semantics guarantee that any second
expansion is a no-op; either way, the end result is a single expansion.
And by making the new definition call m4_require under the hood (plus
whatever magic to avoid a warning), we have guaranteed that no
out-of-order expansion happens. Plus, it will be easy to make
gnulib-common.m4 provide an override of AC_DEFUN_ONCE that works in this
manner even with older autoconf. Thus, 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 that a macro body is only needed once.
I'll work up patches for both the autoconf and gnulib side of things.
- --
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkl55KcACgkQ84KuGfSFAYCRNwCfTacwi6j66kwSN44QKgJ3Z/ro
1RIAnAzUMUV4vAj4NG0w7+AGIHI95uL5
=AYp2
-----END PGP SIGNATURE-----
- Re: expand-before-require bug, Bruno Haible, 2009/01/22
- Re: expand-before-require bug, Bruno Haible, 2009/01/22
- Re: expand-before-require bug, Eric Blake, 2009/01/22
- Re: expand-before-require bug, Paolo Bonzini, 2009/01/23
- Re: expand-before-require bug, Bruno Haible, 2009/01/23
- Re: expand-before-require bug, Paolo Bonzini, 2009/01/23
- Re: expand-before-require bug, Paolo Bonzini, 2009/01/23
- Re: expand-before-require bug,
Eric Blake <=
- Re: expand-before-require bug, Bruno Haible, 2009/01/23
- Re: expand-before-require bug, Eric Blake, 2009/01/23
- Re: expand-before-require bug, Bruno Haible, 2009/01/23
- Re: expand-before-require bug, Eric Blake, 2009/01/25
- Re: expand-before-require bug, Paolo Bonzini, 2009/01/26
- Re: expand-before-require bug, Ralf Wildenhues, 2009/01/26
- Re: expand-before-require bug, Ralf Wildenhues, 2009/01/26