-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Ralf Wildenhues on 10/31/2008 1:13 AM:
Hi Ralf, all,
>
> No warning that, since the aim was to move away from the old semantics
> to the new semantics, using `-' gets the user stuck with the old
> semantics which means he will put stones in the way of the intended
> move?
Jeff, which solution did you use for your particular problem? I'm reading
between the lines and assuming that you ended up passing something besides
[] or [-], because you wanted a compiler check (which rejects the header
as incompatible with your usage patterns) and not a preprocessor check
(which accepts the header as present).
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.
>
> I think a decent documentation should at least caution this as a
> last resort, and in conjunction with the warning, the normal use of the
> fourth argument should be suggested first. To make this clear: the
> recommendation to list #includes in the fourth argument should be the
> first one after the "Present But Cannot Be Compiled" warning, as that's
> where people are going to start reading, if they didn't find the FAQ
> entry.
Any suggested wording for this? I'll start working on a patch that swaps
the default behavior to favor the compiler results, and make the
documentation more explicit that using [-] as the fourth argument is
generally the wrong approach. But this time, I'll post the patches for
review rather than just pushing a doc patch ;)
>
> I take it that this is a decision to be stuck with the preprocessor test
> forever? How about the idea of using a special argument to denote "try
> a compile test, but if it fails, then don't output that horrendous
> warning"?
The point of the current implementation is that if you supply anything
other than [] or [-], then there is no warning, and only the compiler
result is trusted. The problem is that there is a large base of code that
uses [] as the (possibly implicit) fourth argument. But we've been
warning for a couple of years (witness how often people have been
reporting bugs to this list on older autoconf versions that used autoconf
rather than the package's bug reporting address in the warning message),
so hopefully package maintainers have gotten the hint.
>> +For anything else, only a compiler check is performed, using
>> [EMAIL PROTECTED] as the set of preprocessor directives to use prior to
>> +including the header under test, in which case, it is common to manually
>> +list @code{AC_INCLUDES_DEFAULT} (@pxref{Default Includes}) along with
>> +any other prerequisite headers.
>
> Yeah, most users won't notice the need for prerequisite headers even for
> the preprocessing test.
There are no prerequisites in the preprocessing test - look at Paolo's
patches 6/12 and 7/12 - patch 6 (header_mongrel) covers the case when the
fourth argument is blank, and it uses AC_INCLUDES_DEFAULT only on the
compiler test (the preprocessor test is really whether the file is
present, without regards to its contents). Patch 7 covers the case of [-]
(header_old) and anything explicit (header_new).
Also, things like AC_CHECK_HEADERS_ONCE can't supply a fourth argument,
and hence they always use the header_mongrel implementation. In the past,
this has been an issue on the gnulib list, where you can't do
AC_CHECK_HEADERS_ONCE([ws2tcpip.h]) because it falls in the category of
headers that is present but not compilable on cygwin.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-----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
iEYEARECAAYFAkkLEtkACgkQ84KuGfSFAYBKbACgoHGL8ZVkieq69FGJJlxr9S6I
vwEAoKwJqXXYg37cs0ZunPllawvBj0n2
=Jyok
-----END PGP SIGNATURE-----
_______________________________________________
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
