[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: expand-before-require bug
From: |
Bruno Haible |
Subject: |
Re: expand-before-require bug |
Date: |
Fri, 23 Jan 2009 12:13:13 +0100 |
User-agent: |
KMail/1.9.9 |
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
- expand-before-require bug, Eric Blake, 2009/01/21
- Re: expand-before-require bug, Eric Blake, 2009/01/21
- Re: expand-before-require bug, Bruno Haible, 2009/01/22
- Re: expand-before-require bug, Paolo Bonzini, 2009/01/23
- Re: expand-before-require bug, Bruno Haible, 2009/01/23
- Re: expand-before-require bug, Paolo Bonzini, 2009/01/23
- Re: expand-before-require bug, Paolo Bonzini, 2009/01/23
- Re: expand-before-require bug, Eric Blake, 2009/01/23
- Re: expand-before-require bug, Bruno Haible, 2009/01/23
- Re: expand-before-require bug, Eric Blake, 2009/01/23
- Re: expand-before-require bug, Bruno Haible, 2009/01/23
- Re: expand-before-require bug, Eric Blake, 2009/01/25
- Re: expand-before-require bug, Paolo Bonzini, 2009/01/26