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

[Paolo Bonzini]

> I think we're all in agreement on this point - it's time to favor the
> compile check.

Yes, but we have to agree on how. :-)

> I think the warning is still handy - there are too many instances of
> headers that need prerequisites (think <readline/readline.h>, whose man
> page mentions that <stdio.h> must be included first; hmm, we should add
> that example in the manual).

I disagree.  AC_INCLUDES_DEFAULT was added exactly to cater for the
common cases (typically sys/types.h and stddef.h).

> I'd rather see recommendation of a non-empty
> fourth argument to silence it the warning on per-instance basis, rather
> than an AC_REQUIRE that silences across the entire configure.ac.

That's the best way to never see the transition completed.  The point of
the warning was that *by now* we assume that everybody added the fourth
argument in the rare cases it was needed.  Remember that the first part
of the transition was to send bug reports to address@hidden, so
that AC_INCLUDES_DEFAULT could be made as complete as needed.

>> Yes, that's bad.  I made AC_CHECK_HEADERS_ONCE stick with MONGREL even
>> with AC_PREREQ([2.64]).  I'm not sure it's the right thing to do, it's
>> surely the most conservative.
> 
> Maybe a better option would be having AC_CHECK_HEADERS_ONCE take a second
> parameter

Or even four.  There's no reason it should not be able to look (again)
at cache variables at the place of expansion.

> , then instead of maintaining one list (ac_headers_list), we
> would maintain two.

Not so easy.  INCLUDES value A might be incompatible with INCLUDES value
B.  Much better to expand each header check separately as
AC_CHECK_HEADERS([$1],,,[$4]) at the place AC_CHECK_HEADERS_ONCE is
called (using m4_provide_if and getting rid of _AC_HEADERS_EXPANSION).
If $2 and $3 are given, you can follow-up with another for loop to
expand them even if the check had already been done elsewhere.  But I'm
not going to write this patch.

> AC_CHECK_HEADERS_ONCE([ws2tcpip.h], [:]) would actually do the right thing
> on cygwin (silently reject the header as not useful).

So would without my patch, actually, because I did update _MONGREL to
reject useless haders.

> I do like the fact that you want to rename the macros away from
> OLD/NEW/MONGREL to PREPROC/COMPILE/COMPAT, as that describes the situation
> better.  Would you mind splitting the patch, and let's apply the rename
> independently from any later patches for semantic changes?

I will, but notice that it is PREPROC/COMPILE/MONGREL.

COMPAT is the dispatcher for the three macros; NEW is the dispatcher for
PREPROC/COMPILE.

> Again, I'm not sure I favor making AC_PREREQ change the behavior across
> the entire configure.ac package, especially in the context of third-party
> macros.

But bugreports regarding "Present But Cannot Be Compiled" should have
already arrived even for those third party macros.  The point is that
there *must* be a flag day sooner or later, and nobody really forces you
to have AC_PREREQ(2.64) in your configure.ac.

> That won't do what you expect.  You should only reassign
> _AC_PREREQ_VERSION if $1 is greater than any previous request, otherwise a
> later request for a lower version will undo your claim.  But again, I'm
> not sure we should go this route.

Right.

>> +# If INCLUDES is empty, then check both via the compiler and preproc.
>> +# If the results are different, issue a warning.
> 
> Which category of warning?  portability?

No, the good old "Present But Cannot Be Compiled" warning.  But this
time, proceeding with the compiler's result.

>> +#
>> +# If INCLUDES is `-', keep only the old semantics.
> 
> How about we also issue an obsolete warning?

No, deprecating [-] would be a totally different discussion.

>> +#
>> +# If INCLUDES is specified and different from `-', then use the new
>> +# semantics only.
> 
> Should we add a special case where [:] is shorthand for [AC_INCLUDES_DEFAULT]?

Do you seriously think anyone would use it? ;-)  And that's the reason
why I thought about the AC_PREREQ mechanism.  You must have a way to let
the user finish the transition without changing all third-party macros,
or the transition will never finish.

Paolo