Re: AC_CHECK_HEADER

[Alex Zimnitsky]

В Срд, 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