Re: AC_DEFUN_ONCE semantics

[Eric Blake]

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> 
> Hi Eric,
> 
> * Eric Blake wrote on Mon, Jan 26, 2009 at 06:09:28PM CET:
> > * lib/m4sugar/m4sugar.m4 (m4_defun_once): Rewrite to be no-op,
> > rather than warning, on second use, and make sure first use never
> > occurs out of order.
> 
> This means that the user may practically never directly call a
> defun_once'd macro within a shell conditional, right?  Sounds
> like a backward incompatibility to me, hopefully a small one.

Here's some case studies of your question:

AC_DEFUN_ONCE([foo], [bar])
if :; then
  foo
fi

results in the expansion of foo inside the shell conditional.  Since this is 
the only expansion of foo, we are no worse the wear.


AC_DEFUN_ONCE([foo], [bar])
if :; then
  foo
fi
foo

Before the patch, this warns the user that the second attempt to use foo did 
nothing.  After the patch, the second attempt is silent.  But either way, the 
second attempt did not re-expand foo, and if the user notices the problem, they 
should really consider using AS_IF if they need the one-shot foo working both 
inside and outside the conditional.


AC_DEFUN_ONCE([foo], [bar])
AS_IF([:], [foo])

Before the patch, foo was expanded inside the conditional; after the patch, foo 
is hoisted and expanded before the conditional.  Yes, hopefully this is a small 
incompatibility; but hopefully it only results in longer execution time in the 
case where the shell condition used to skip the processing of foo.  I guess 
this also means that we have an additional rule of thumb: if there is ever any 
reason why the macro should _not_ be blindly hoisted outside of all other 
defun'd macros, then don't use AC_DEFUN_ONCE, because the macro is not truly 
one-shot if it is not safe to hoist.  Do you want me to add text along these 
lines to the AC_DEFUN_ONCE documentation?

-- 
Eric Blake