Re: preparation for expand-before-require warning

[Eric Blake]

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