Eric Blake <ebb9 <at> byu.net> writes: > > Libtool uses an idiom that is now warned about. > 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. >
I've factored it down to this: m4_defun([a],[1]) m4_defun([b],[2 m4_require([a])]) m4_defun([c],[3 a b]) c => 3 1 2 which is silent (as desired), but adding one more macro in the mix: m4_defun([a],[1]) m4_defun([b],[2 m4_require([a])]) m4_defun([c],[3 a b]) m4_defun([d],[4 m4_require([c])]) d => 1 3 1 2 4 warns, and ends up (needlessly) re-expanding a; the optimal output would be '3 1 2 4'. The problem is that the presence of d requiring c was enough to make b requiring a think it was in a nested require situation. So it looks like I need to be a bit more careful about detecting expand-before-require, perhaps by changing m4_provide to track which diversion a macro was provided in, rather than its current usage of a binary check of whether it is provided at all. I'm still thinking about the solution, but I think it should be possible to silence this false positive before autoconf 2.64. -- Eric Blake
