[Python-Dev] Good way of finding out what C functions we have?

Brett C. bac at OCF.Berkeley.EDU
Tue Sep 30 17:41:12 EDT 2003


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




More information about the Python-Dev mailing list