Re: expand-before-require bug

[Bruno Haible]

Hi Eric,

> * modules/errno (configure.ac): Require, rather than expand,
> gl_HEADER_ERRNO_H.
> * m4/errno_h.m4 (gl_HEADER_ERRNO_H_BODY): Merge...
> (gl_HEADER_ERRNO_H): ...into this macro, and use AC_DEFUN_ONCE to
> enforce that all clients require it.

This change is a step backwards. It makes the problem worse.

The problem that you discovered is that *some* AC_DEFUNed macros
should be expanded once, and autoconf has a problem with that in
particular conditions. That is, if the macro is both invoked and
required, there is a problem.

So my and your workaround (in gl_HEADER_ERRNO_H and gl_MULTIARCH) was to
write and publish macros for which, when they are both invoked and
required, there is *no* problem. This is a good step because ultimately
it eases maintenance if we don't have to remember "this macro must only
be invoked" and "that macro must only be required".

Your two patches now reintroduce the problem. But no, I don't want to
think about AC_REQUIRE's bug every time I want to invoke an autoconf macro!

> but since that macro in turn merely required 
> gl_HEADER_ERRNO_H_BODY, there was no actual out-of-order output (I don't know 
> any way to easily teach autoconf to avoid a false positive warning on a macro 
> that merely requires another macro as its sole content).

You realize that the warning is a false positive. So, there was no problem
with gnulib's macros here. Can you please revert the two patches?

The question what to do with the warning then is of secondary nature. You can
  - make it a non-default warning (like -Wshadow in gcc - not part of -Wall), or
  - fix the warning to apply only to AC_DEFUN_ONCEd macros. After all, I used
    AC_DEFUN, not AC_DEFUN_ONCE, to define gl_HEADER_ERRNO_H. Then why do you
    emit a warning about it at all?
  - fix the warning to recognize macros which, other than for AC_REQUIRE
    invocations, produce only whitespace output, or (better)
  - provide a documented way to avoid the warning for a particular macro,
    I much prefer to have a macro which can be both invoked and required,
    even if it requires one more line of code to write it down, than to have
    a macro with restricted use.

Bruno