Re: Disable the present-but-cannot-be-compiled header warning?

[Ralf Wildenhues]

Hi Eric, all,

* Eric Blake wrote on Fri, Oct 31, 2008 at 05:06:33AM CET:
> --- a/doc/autoconf.texi
> +++ b/doc/autoconf.texi

> @@ -5803,9 +5803,20 @@ Generic Headers
>  header file is available, consider using @code{AC_CHECK_HEADERS}
>  instead.
>  
> address@hidden is a series of include directives, defaulting to
> address@hidden (@pxref{Default Includes}), which are used
> -prior to the header under test.
> address@hidden is decoded to determine the appropriate include
> +directives.  If omitted, @file{configure} will check for both header
> +existence (with the preprocessor) and usability (with the compiler),
> +using @code{AC_INCLUDES_DEFAULT} for the compile test.  Currently, if
> +there is a discrepancy between the results, a warning is issued to the
> +user, and the preprocessor results are favored (@pxref{Present But
> +Cannot Be Compiled}); but a future release may switch to favoring the
> +compiler results.  If @var{includes} is exactly @samp{-}, then only a
> +preprocessor check is performed, without regard to prerequisite headers.

No warning that, since the aim was to move away from the old semantics
to the new semantics, using `-' gets the user stuck with the old
semantics which means he will put stones in the way of the intended
move?

I think a decent documentation should at least caution this as a
last resort, and in conjunction with the warning, the normal use of the
fourth argument should be suggested first.  To make this clear: the
recommendation to list #includes in the fourth argument should be the
first one after the "Present But Cannot Be Compiled" warning, as that's
where people are going to start reading, if they didn't find the FAQ
entry.

I take it that this is a decision to be stuck with the preprocessor test
forever?  How about the idea of using a special argument to denote "try
a compile test, but if it fails, then don't output that horrendous
warning"?

> +For anything else, only a compiler check is performed, using
> address@hidden as the set of preprocessor directives to use prior to
> +including the header under test, in which case, it is common to manually
> +list @code{AC_INCLUDES_DEFAULT} (@pxref{Default Includes}) along with
> +any other prerequisite headers.

Yeah, most users won't notice the need for prerequisite headers even for
the preprocessing test.

Cheers,
Ralf