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
