[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_DEFUN_ONCE semantics
From: |
Eric Blake |
Subject: |
Re: AC_DEFUN_ONCE semantics |
Date: |
Wed, 04 Feb 2009 06:04:52 -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 Ralf Wildenhues on 2/3/2009 11:55 AM:
> At the same time, you lose out on a probably slightly unusual case which
> previously was pretty harmless but has now turned into a mine: a case
> where the user used these macros in several branches of a shell
> conditional construct:
> case $foo in
> bar) MACRO ;;
> baz) ;;
> *) MACRO ;;
> esac
>
> These things (used to) work fine more often than not, and now you break
> them silently. And what's more important: there really are cases where
> it is so much easier to invoke macros shell-conditionally.
In the case of macros that were already AC_DEFUN_ONCE, there is no
semantic change. But for macros which were previously AC_DEFUN, but which
we convert to AC_DEFUN_ONCE, yes, this is a potential mine, which is why
we should minimize which macros undergo the conversion unless we have good
reason to believe that the macro will not be used conditionally.
>
> Why not instead let autoconf warn about instances other than the first
> one? Whether you then decide to expand them nonetheless, or not is then
> less of a correctness concern.
Warning would defeat the purpose of using AC_DEFUN_ONCE to avoid the
warning of multiple expansions. We could, however, rewrite the
problematic macros as AC_DEFUN with a self-redefinition that warns on
subsequent expansions, and have that be the state of affairs for a release
cycle prior to switching over to AC_DEFUN_ONCE.
>
> Anyway, I do think that turning macros to be defun-once'd is something
> akin of an API change of these macros, and as such, the list of affected
> macros should be put in NEWS at least (and probably also annotated in
> the manual).
Highly agreed; I'll add a NEWS entry with all of the affected macros.
- --
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
iEYEARECAAYFAkmJknQACgkQ84KuGfSFAYALUwCeMNuPLb5Oab7AP6JicSGa41YP
0YwAoKjK40yguEmBDRg+cOL60xnAjpoE
=MRw/
-----END PGP SIGNATURE-----