autoconf
[Top][All Lists]
Advanced

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

Re: New failures with autoconf master


From: Zack Weinberg
Subject: Re: New failures with autoconf master
Date: Wed, 25 Mar 2020 15:17:48 -0400

On Wed, Mar 18, 2020 at 12:13 PM Nick Bowler <address@hidden> wrote:
> On 18/03/2020, Nick Bowler <address@hidden> wrote:
> > On 2020-03-18, Ross Burton <address@hidden> 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.

I think this counts as a regression and we do need to fix it so
existing configure scripts continue to work.  See the third of the
three patches I just posted.

I was able to confirm that this was indeed the problem with both flex and nasm.

zw



reply via email to

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