-----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 ebb9@xxxxxxx -----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----- _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
