On 18/03/2020, Nick Bowler <nbow...@draconx.ca> wrote: > On 2020-03-18, Ross Burton <ross.bur...@intel.com> wrote: > [...] >> The flex issue is worked around by picking this commit from flex git: >> >> https://github.com/westes/flex/commit/c42de062bbdc7c31d7181c10a74202d493280ada >> >> That refers to a mail sent to bug-autoconf in February 2018, with no >> reply: >> >> https://lists.gnu.org/archive/html/bug-autoconf/2018-02/msg00005.html > [this mail describes observed problems when passing a literal 'dnl' to the > first argument of AC_CHECK_FUNCS] >> >> Any thoughts? > > I think the linked mail stems from a misunderstanding of how m4 and > "dnl" work. > > "dnl" is not really a comment like you may find in other programming > languages. It is a macro, but one with very special semantics in that it > influences how m4 parses the remaining input whenever it is expanded. > > The first argument to AC_CHECK_FUNCS is not subject to further expansion > within the expansion of AC_CHECK_FUNCS (very typical for macros which > take "string" arguments" in M4), so by quoting the dnl this means it is > never expanded and thus has no effect on the M4 processing. So you have > a string containing these characters.
Ah, I see now: while the first argument to AC_CHECK_FUNCS is treated as a "string" when splitting on whitespace to generate the list of function names for Autoheader, it is not treated the same when creating the for loop. This is probably a mistake and the first argument should not be subject to further expansion in any case. In master it seems this was further changed to use an unrolled loop in some simple cases which may result in some altered behaviour compared to autoconf 2.69. Cheers, Nick
