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
