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