Re: preparation for expand-before-require warning

[Eric Blake]

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> Libtool uses an idiom that is now warned about.  For example, in
> libltdl/m4/libtool.m4, it warns about
> 
> m4_defun([_LT_PROG_CXX],
> [
> pushdef([AC_MSG_ERROR], [_lt_caught_CXX_error=yes])
> AC_PROG_CXX
> if test -n "$CXX" && ( test "X$CXX" != "Xno" &&
>     ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) ||
>     (test "X$CXX" != "Xg++"))) ; then
>   AC_PROG_CXXCPP
> else
>   _lt_caught_CXX_error=yes
> fi
> popdef([AC_MSG_ERROR])
> ])# _LT_PROG_CXX

Thanks for the report.  Yes, I saw that, too, and that is my next project to 
tackle.  In this case, I think that backwards-compatibility argues that an 
older libtool and newer autoconf should play together nicely, so I agree that 
we should try to silence the warning at the autoconf level if there is no real 
out-of-order bug.  And looking at the definition, we really do have an instance 
of expanding a macro immediately before it is required by the next macro we 
directly expand (I don't see any indirect AC_REQUIRE when viewing _LT_PROG_CXX 
in isolation).  I thought I was already special casing direct requires; but 
maybe what is happening is that my special case only works at the top level, 
while _LT_PROG_CXX is occurring inside a level of AC_REQUIRE.

Since it looks like I still have a false positive in the loop, I'm trying to 
factor this down to a smaller testcase, at which point I can then try and 
figure out how to avoid the warning.

-- 
Eric Blake