[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Zack Weinberg
Subject: [sr #110325] autoupdate introduces a second invocation of AC_OUTPUT
Date: Mon, 13 Jun 2022 11:47:17 -0400 (EDT)

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

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

Fun fact: `dnl ...` is _not_ a comment as far as M4 is concerned, but `# ...`
_is_ !  See
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
) 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

`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


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:


Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]