Skip Montanaro wrote:
>> I would look in pyconfig.h.in as the first thing. There is a pitfall, >> though: presence of some HAVE_foo in pyconfig.h does not mean that >> Python gracefully deals with the absence of foo. When converting >> configure to autoconf 2.5x, I checked all macros to determine whether >> they were still in use, but some may have become unused/not processed >> correctly since. That would be a bug, of course.
Brett> What does happen if a HAVE_foo is actually required? Does the Brett> build fail or will configure halt and say that the build will Brett> fail if you proceed?
It's not exactly clear what you mean by "required".
As in Python will not be at all functional without the functionality being required.
All the HAVE_foo macros are supposed to indicate the presence (when defined) or absence (when not defined) of a particular "feature" which is not felt by one or more of the authors to be universally available. As far as I know, a HAVE_foo macro should never be required to be defined, though I suppose if we had an infinite amount of time on our hands be might code a configure test for HAVE_WRITE. HAVE_* macros should only be used in a conditional way like
#ifdef HAVE_FOO /* assume foo is available */ else /* assume foo is missing and code around its absence */ endif
or as in the case of fsync() in posixmodule.c
#ifdef HAVE_FSYNC /* define wrapper for fsync() endif
The lack of a HAVE_foo macro definition might make an entire module unavailable. More often it causes a single module function to not be defined or for a messier or less efficient implementation to be used.
Right. I was wondering if there are any checks in configure.in that if something was not available that Python itself would not compile *at all*. I would suspect not since that is what the ANSI C/POSIX coding requirement is supposed to handle, right? -Brett