Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes: > with current git Autoconf, I get a warning with this setup (distilled > from the OpenMPI): > > AC_DEFUN([A], > [pristine_CC=$CC > AC_PROG_CC > echo "before: $pristine_CC, after: $CC" > ]) > > AC_DEFUN([B], > [AC_REQUIRE([A]) > AC_REQUIRE([AM_PROG_CC_C_O]) > ]) > > AC_INIT(a,1) > AM_INIT_AUTOMAKE([foreign]) > B > AC_CONFIG_FILES([Makefile]) > AC_OUTPUT
> What can be done about this, ideally without compromising the > factorization into macros and without the $pristine_CC variable > set/usage losing meaning? (Similar issues exist for other macros.) As distilled as it is, we're still pulling in automake text. So I tried to simplify it even further, and came up with the following, mapped back to your example: m4_defun([a],[1]) dnl AC_PROG_CC m4_defun([b],[2 a 3]) dnl A m4_defun([c],[4 m4_require([a])]) dnl AC_PROG_CC_C_O m4_defun([d],[5 m4_require([c])]) dnl AM_PROG_CC_C_O m4_defun([e],[6 m4_require([b]) m4_require([d])]) B e 2 1 3 m4trace:stdin:7: -1- _m4_warn([syntax], [m4_require: `a' was expanded before it was required], [stdin:4: c is expanded from... stdin:5: d is expanded from... stdin:6: e is expanded from... stdin:7: the top level]) 1 4 5 6 But indeed, when expanding c, the text for a has already been output, so this looks like another false positive that I should try to silence. Previously, I was assuming that if the diversion where text was expanded differs from the diversion doing the require, then we have an out-of-order scenario. But here, the diversion doing the expansion has been collected; so I need to figure out how to make the check for false positives recognize whether the location doing the expansion has been collected yet. Thanks for the report, and hopefully I'll have something soon, once I can figure out an efficient way to distinguish this without breaking any of the existing autoconf tests. -- Eric Blake
