Re: expand-before-require bug

[Bruno Haible]

Hi Eric,

> > But no, I don't want to
> > think about AC_REQUIRE's bug every time I want to invoke an autoconf macro!
> 
> My argument is that if Autoconf can enforce rules, such as refusing to
> compile if you try to expand instead of require an AC_DEFUN_ONCE macro,
> then it is easy to fix your code if you choose the wrong method.

From the perspective of a user of autoconf, who writes and maintains many
macros: Yes I like it if autoconf tells me through errors or warnings,
when I'm using a macro in the wrong way. But it is even better if both
ways to use a macro are possible and produce correct results.

> Requiring then expanding for AC_DEFUN is generically ok (although you get
> redundant expansion, so the output is larger); the problem is only with
> expanding then requiring.

In some cases - the idempotent macros - there is no problem in either case.
I'm asking for a way to declare to autoconf (and to the user of the macros)
that a macro can be used either way.

> It is next to impossible to efficiently figure out whether an m4 macro
> body consists of only whitespace and AC_REQUIRE.

Yes. And then there's also the case of idempotent macros that don't
entirely consist of whitespace, like e.g.

AC_DEFUN([my_INIT],
[
  PACKAGE_HOMEPAGE='http://www.gnu.org/gnu/foobar'
])

> >   - macros defined with AC_DEFUN_IDEMPOTENT are *known* to be expandable
> >     any number of times, hence they may be both invoked and required,
> 
> I suppose I could implement this for 2.64:
> 
> m4_define([AC_DEFUN_IDEMPOTENT],
> [m4_set_add([_m4_idempotent], [$1])AC_DEFUN([$1], [$2])])
> 
> then make the warning conditional on whether the macro is a member of the
> set.

Yes, thanks, that would solve the major problem of this thread.

> But this definition won't port back to 2.63 or earlier, so gnulib 
> would have to do something like this fallback:
> 
> m4_ifndef([AC_DEFUN_IDEMPOTENT],
> [m4_define([AC_DEFUN_IDEMPOTENT], m4_defn([AC_DEFUN]))])

Sure, gnulib can accommodate fallbacks in m4/gnulib-common.m4.

> Meanwhile, you still have the scenario where a macro declared idempotent
> may result in duplicated output when using 2.64 (okay, since you declared
> it was idempotent), but silent out-of-order expansion when using 2.63 or
> earlier.  Which means the onus is thus on the developer using
> AC_DEFUN_IDEMPOTENT to ensure that their macro consists only of whitespace
> and AC_REQUIRE, if they don't want to be impacted by expand-before-require
> bugs.  But autoconf can't enforce that a macro declared idempotent was
> well-written.

Yes, this is the idea: The programmer guarantees a property of the macro
that autoconf has no chance of verifying.

> But again, this improved warning is only
> available if you develop with autoconf 2.64, so it is still possible that
> developers using older autoconf will introduce bugs.

Not a big problem. We'll encourage people to migrate to 2.64 ;-)

> > So for your warning about required-after-expanded it means:
> >   - the warning should apply always to AC_DEFUN_ONCEd macros,
> 
> To be clear, you are proposing multiple warnings.  In this case, one
> warning is attached to any direct expansion of a defun_once macro inside a
> defun macro body, regardless of any other requires that have taken place:
> 
> `macro' should be AC_REQUIRE'd inside AC_DEFUN

Yes, indeed, this is also a good warning to be issued. So, in summary,
there will be these three warnings, right?
  - when an AC_DEFUN_ONCEd macro is expanded twice,
  - when an AC_DEFUN_ONCEd macro is expanded inside AC_DEFUN or 
AC_DEFUN_IDEMPOTENT,
  - when an AC_DEFUNed macro is being required after having already been 
expanded.

> >   - the warning should never apply to AC_DEFUN_IDEMPOTENTd macros,
> 
> possible, but puts the onus on the user to use this style of macro
> definition wisely

Sure. It's the developer's responsibility to use AC_DEFUN_IDEMPOTENT only
when the macro is really idempotent.

> >   - the warning should apply to AC_DEFUNd macros only when the warning
> >     level is higher than the default. The warning should indicate that
> >     either the double expansion is a problem, or the macro should be
> >     changed to be defined with AC_DEFUN_IDEMPOTENT if it is not a problem.
> 
> Here, the warning should always be issued.

OK, fine, I can agree to that.

Bruno