В Срд, 05/08/2009 в 01:23 +0200, Paolo Bonzini пишет: > > Well, warnings are to show that something is wrong, and protecting > > includes with #error is right, at least in FreeBSD realm. Perhaps it's > > not a bad idea to use AC_INCLUDE_DEFAULTS or some other mechanism when > > checking a header with preprocessor (at least on FreeBSD). > > I think that if the presence check makes no sense for this header, the > four-argument version with AC_INCLUDES_DEFAULT should be used always. >
so be it > > 2. places AC_PREPROC_IFELSE before AC_COMPILE_IFELSE in > > _AC_CHECK_HEADER_MONGREL_BODY > > I would like the maintainers of Autoconf to come back from holiday and > comment on this one. > I'd like to expand on that one 1) by user i mean the person who _runs_ "./configure", not the one who creates configure.in (pkg maintainer). The user is not supposed to know autotools, otherwise there is no purpose of "./configure" being self-contained and pre-generated. one may say that this kind of user only needs to check the total result of "./configure" (to run or not to run make), well, i strongly object to this. 2) Once there was only one type of check (preprocessor), so what actually happened was even better than what was reported to the user: ------------important------------------ user was reported that the file existed, while in reality that file was additionally checked for being a valid header: checking for ... presence... no --------------------------------------- 3) It turned out, that to be a valid header is not enough, because headers usually constitute some hierarchy, and have prerequisites which would rather be checked for presence as well. 4) This issue is resolved with actual compilation, which became the new way of checking headers. This new way was named "checking for usability". This is exactly what is reported to the user ---------------important---------------------- user is reported that the file is usable, because that is what just have been done: "./configure" used it in a way that the header is used in actual software checking for ... usability... yes ---------------------------------------------- 5) Now watch the hands! Better-than-truth and complete-truth put together produce confusion and misinformation of the user! --------------important-------------------------- When a user sees checking for ... usability... yes checking for ... presence... yes he thinks that maybe the output lines only are misplaced, but the tests are carried out in the right order (presence first, usability next), what he definitely assumes is that those tests are _related_. what is he supposed to think seing this? checking for ... usability... yes checking for ... presence... no even when the output is like this checking for ... presence... no checking for ... usability... yes it no better, because presence-usability make strong relation and order, while those test results ruin it. ----------------------------------------------------- 6) the warning message, which acompanies this pretends to explain, but in fact does not shed much light on the situation. With that "!" at the end it tells, that what happened (gcc Ok, gcc -E fail) is very strange and cannot happen, but it happened... so, what i propose: 1) Change wording and forget about that patch of mine: checking for ... presence checking for ... with preprocessor checking for ... usability checking for ... with compiler looks good enough for me and does not misinform the user whether used alone or in any combination 2) If changing wording is not an option, reorder the lines usability-presence (my patch), this will keep misinforming users though. 3) Change the warning: accepted by the compiler, rejected by the preprocessor! proceeding with compiler's result accepted by the compiler, rejected by the preprocessor the header may be protected from inclusion with #error check, if it really needs to be included directly proceeding with compiler's result best Alex
