Re: [sr #110215] AC_EGREP_HEADER appears to be broken in master
Nick Bowler <[email protected]>
| Newsgroups | gmane.comp.sysutils.autoconf.bugs |
|---|---|
| Message-ID | <CADyTPEz9WFBVJ-XqrO-F8w77+9Bsak7N+DqzugTwzKBT5DWVzw@mail.gmail.com> |
Hi Ross, On 2020-03-24, Ross Burton <[email protected]> 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