Re: plans?

[Eric Blake]

On 08/26/2010 12:42 PM, Ralf Wildenhues wrote:
> > I'm also hoping to address Bruno's idea of AC_RUN_IFELSE and
> > friends doing some more sanity checking that their program body was
> > provided by AC_LANG_SOURCE.
>
> Do you have an idea for an implementation yet?

Why yes I do - funny you should ask!

All four of AC_{PREPROC,COMPILE,LINK,RUN}_IFELSE document that their 
first argument must be non-empty, but then call _AC_*_IFELSE to do the 
real work, and those macros allow an empty run (assuming that if you 
passed an empty argument, you are responsible for pre-creating 
conftest.$ac_ext yourself).  But for non-empty arguments, they all go 
through AC_LANG_CONFTEST([$1]) to expand the given text into the file 
conftest.$ac_ext.

And AC_LANG_PROGRAM calls AC_LANG_SOURCE under the hood, so we really 
only have to test whether AC_LANG_SOURCE was (indirectly) invoked during 
the body of AC_LANG_CONFTEST for non-empty program text.

So the idea is that AC_LANG_CONFTEST should pushdef a variable, expand 
$1, warn if the variable was not modified, and popdef; and that 
AC_LANG_SOURCE modifies the variable as evidence that a fully 
functioning program, including all prior AC_DEFINEs, was properly used.

Then, for the few places that really do generate their own program 
without needing all prior AC_DEFINEs (if we find any), we also expose a 
macro that can modify that variable in the same was as AC_LANG_CONFTEST.

So, if you get the warning, you either need to rewrap your program text 
in AC_LANG_SOURCE, or add a call to the new macro stating that you know 
what you are doing, in order to silence the warning.

Most likely, the hardest work will be just writing the testsuite 
exposure, and especially in the case of nested checks (such as running 
AC_RUN_IFELSE in the if-true leg of an outer AC_LINK_IFELSE).

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org