[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: |
Nick Bowler |
Subject: |
Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master |
Date: |
Tue, 24 Mar 2020 13:24:24 -0400 |
Hi Ross,
On 2020-03-24, Ross Burton <address@hidden> wrote:
[...]
> AC_CHECK_FUNC(statvfs,[HAVE_STATVFS=yes])
> dnl Arg, linux and bsd put their statfs function in different places
> if test x"$HAVE_STATVFS" != x"yes"; then
> AC_EGREP_HEADER(statfs,sys/vfs.h,[AC_DEFINE(HAVE_VFS_H)],[
>
> AC_EGREP_HEADER(statfs,sys/mount.h,[AC_DEFINE(HAVE_MOUNT_H)],[AC_MSG_ERROR(failed:
> Need statvfs)])
> ])
> fi
> (and later looks for h_errno then fails)
>
> And the generated code does this:
>
> if test x"$HAVE_STATVFS" != x"yes"; then
> { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for grep that
> handles long lines and
> -e" >&5
> printf %s "checking for grep that handles long lines and -e... " >&6; }
> ...
>
> So the search for egrep only happens if statvfs isn't found by
> AC_CHECK_FUNC. My understanding is that this isn't how AC_REQUIRE
> should be working, right?
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_.
This is almost never the desired behaviour because autoconf will
consider the macro expanded and will not expand the dependency at other
AC_REQUIRE sites, leading to the problem you see.
There are several options for configure authors can to avoid this
problem, including:
(1) You can use AS_IF, which will cause m4 to hoist the dependency
expansion outside of the conditional.
(2) You can explicitly call all dependencies such as AC_PROG_EGREP
outside of the if.
Obviously (2) is only possible if you know the dependencies in advance
(not so good for externally-updated macros) so I suggest using AS_IF.
Hope that helps,
Nick
[sr #110215] AC_EGREP_HEADER appears to be broken in master, Ross Burton, 2020/03/24