[sr #110325] autoupdate introduces a second invocation of AC_OUTPUT

[Zack Weinberg]

Follow-up Comment #3, sr #110325 (project autoconf):

> So, M4-level `dnl` comments are one thing, but how about shell-level `#`
comments?

Fun fact: `dnl ...` is _not_ a comment as far as M4 is concerned, but `# ...`
_is_ !  See
https://www.gnu.org/savannah-checkouts/gnu/m4/manual/html_node/Comments.html
and https://www.gnu.org/savannah-checkouts/gnu/m4/manual/html_node/Dnl.html .

We don't usually think of `# ...` as a M4 comment because it's included in the
output, but the thing is, it's included in the output _verbatim_.  An unquoted
`#` (or more precisely, whatever the current "begin-comment delimiter" string
is, see
https://www.gnu.org/savannah-checkouts/gnu/m4/manual/html_node/Changecom.html
) tells M4 to copy text to the output (or current diversion) _without macro
expansion_ from that point until the end of the line (current "end-comment
delimiter").

`dnl`, by contrast, is a built-in macro with abnormal argument syntax, and it
can be disabled just like any other built-in macro.  People _use_ it for
comments that they want stripped from the M4 output, but that's not what it
was included in M4 for originally -- its actual design purpose is to join
input lines (hence the acronym, "delete [the following] new line").

The bug here is precisely that autoupdate wants to preserve `dnl ...` comments
in its output, but has no way to do so without also subjecting the `...` to
macro expansion.  This is what I meant by "a new feature in M4 itself --
allowing more than one comment starter to be active at once": if


undefine([dnl])
changecom([#],[
],[dnl],[
])


meant that _either_ `#` _or_ `dnl` began an M4-style comment -- copied
verbatim to the output -- running until the end of the line, then autoupdate
could use that to DTRT with the original test case.

> my style decision to combine the two into `dnl#` comments

I believe this stylistic change will also work around this particular bug in
autoupdate, yes, except that you might want to double-check that it doesn't
cause this


dnl# Check for the headers we need
AC_CHECK_HEADERS_ONCE([foo.h bar.h])


to turn into nothing at all (i.e. the AC_CHECK_HEADERS_ONCE line is lost) when
processed by either normal autoconf or autoupdate.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?110325>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/