bug-autoconf
[Top][All Lists]
Advanced

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

Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master


From: Ross Burton
Subject: Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master
Date: Tue, 24 Mar 2020 19:17:21 +0000

On Tue, 24 Mar 2020 at 17:24, Nick Bowler <address@hidden> wrote:
> No, this is exactly how AC_REQUIRE is supposed to be working.  The configure
> script has a bug.  Now I'm not sure why this fails for you only with latest
> autoconf, because AC_REQUIRE has worked like this for a very long time.  It
> might have worked by luck because some earlier macro previously used
> AC_PROG_EGREP, and maybe it no longer does.
>
> The result of expanding AC_REQUIRE'd macros are hoisted to the outermost
> macro expansion (although note that only macros defined with AC_DEFUN
> and friends will participate in this process).
>
> So if you have an open-coded shell "if" outside of any macro, then
> within the if body, you expand a macro that uses AC_REQUIRE, then the
> AC_REQUIRE'd macro gets expanded _within the if_.

So my understanding was that the macros get hoisted up was correct,
but the caveat that bare if needs to be AS_IF was missing.
Understood.

As to why this is not broken with 2.69, I think I have a theory.

If I build e.g. acl with both 2.69 and master, it's notable that 2.69
has these lines in the output that do not exist in master:

> checking how to run the C preprocessor... gcc  -E
> checking for grep that handles long lines and -e... 
> /scratch/poky/hosttools/grep
> checking for egrep... /scratch/poky/hosttools/grep -E
> checking for ANSI C header files... yes

Something else was causing the egrep search to happen early in the
build.  My hunch is that the same codepath exists in apt, and now
isn't expanding egrep earlier in the configure run.

Thanks for the explanation, I'll switch out if for AS_IF and move on.

Ross



reply via email to

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