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
