[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_DEFUN_ONCE semantics
From: |
Ralf Wildenhues |
Subject: |
Re: AC_DEFUN_ONCE semantics |
Date: |
Tue, 3 Feb 2009 19:55:11 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hello Eric,
* Eric Blake wrote on Tue, Feb 03, 2009 at 05:41:49PM CET:
> Eric Blake <ebb9 <at> byu.net> writes:
>
> > I've trimmed my original proposal down to two smaller patches; I'm
> > inclined to submit the first one today, but hold off on the second
> > for another 72 hours in case anyone can find a reason why
> > AC_PROG_INSTALL or AC_PROG_MKDIR_P should be expanded more than
> > once.
> >
> > $ git pull git://repo.or.cz/autoconf/ericb.git m4-require
>
> I'm interpreting silence as consent, and pushing this:
No, silence on my part was not due to consent; but of course you don't
need my consent to go ahead. Sorry about the delay (I've still not read
all mails on this topic).
Here's my take on this whole AC_DEFUN_ONCE business, as far as I
understand it: you lose correctness while maybe gain optimization: You
gain something in cases that are at least slightly dubious or unusual,
but otherwise completely harmless (multiply expanded macros due to users
explicitly invoking them more than once), and what you gain is mostly
negligible: the size reduction in configure should be just as negligible
as the runtime speedup (testing one cache variable repeatedly).
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.
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.
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).
Or maybe I've understood you all wrong the whole time, then please just
correct me.
Thanks,
Ralf