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

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Paolo Bonzini on 10/31/2008 9:59 AM:
>> In which case, I agree with Ralf - the preprocessor check is broken more
>> often than it is correct.  We've had the warning long enough; I think now
>> is an acceptable time to swap the default and favor the compiler check
>> over the preprocessor check.
> 
> Yes, probably.

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

> 
> However, notice this won't help Jeff because he wanted really really no
> warning.  So the attached patch suppresses the warning completely if
> AC_PREREQ([2.64]) (actually anything > 2.63) is given.  What do you
> think?  (testsuite running except for the relevant tests).

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'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.

> 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, then instead of maintaining one list (ac_headers_list), we
would maintain two.  If you pass no second argument, you get the double
check and warning (the header is appended to ac_headers_compat_list), if
you pass a second argument of [:], you get only the compile check and no
warning (the header is appended to ac_headers_compile_list), any other
second argument gives a warning.  Then, in gnulib's case,
AC_CHECK_HEADERS_ONCE([ws2tcpip.h], [:]) would actually do the right thing
on cygwin (silently reject the header as not useful).

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?


> +** Stricter header tests.  As planned in Autoconf 2.56 (released in
> +   2002), AC_CHECK_HEADER and AC_CHECK_HEADERS are now honoring the
> +   compiler result rather than the preprocessor result.  Furthermore,
> +   adding AC_PREREQ([2.64]) to your configure.ac file will disable
> +   the preprocessor test altogether.

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.

>  # AC_PREREQ(VERSION)
>  # ------------------
>  # Complain and exit if the Autoconf version is less than VERSION.
> -m4_undefine([AC_PREREQ])
> -m4_copy([m4_version_prereq], [AC_PREREQ])
> +AC_DEFUN([AC_PREREQ],
> +[m4_version_prereq([$1])m4_define([_AC_PREREQ_VERSION], [$1])])

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.

> +#
> +# 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?

> +#
> +# If INCLUDES is `-', keep only the old semantics.

How about we also issue an obsolete warning?

> +#
> +# 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]?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkLMSkACgkQ84KuGfSFAYAnjwCcDaWsUnFoP8OoPhKwtSQLUt9y
80UAoIUsHhxfJWuFNdvu2XymM+pcNhtM
=TaPn
-----END PGP SIGNATURE-----