autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: preparation for expand-before-require warning


From: Eric Blake
Subject: Re: preparation for expand-before-require warning
Date: Wed, 21 Jan 2009 22:06:19 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]