Martin v. Löwis wrote:

"Brett C." writes:

...

Does there happen to be a better way to find out what functions we check for beyond grepping configure.in? The entire reason I bothered to do so much research is I thought we were only supposed to assume ANSI C with POSIX (which, from what I can tell, strdup() is not).

Actually, strdup is in POSIX:

http://www.opengroup.org/onlinepubs/007904975/functions/strdup.html

Shows how much I know; I found that last night but since it didn't say POSIX anywhere I thought it was part of another standard. I guess the "Issue 5" mention means that BASE is POSIX? Or is IEEE 1003.1 basically POSIX?

If we still check for it, it is because it might not have been available on some system, at some point in time.

We don't only check for it, but we have a replacement implementation (the comment for Python/strdup.c seems to suggest it is needed by the parser).

...

Because of this I would like to list in the Python development guide I am writing up all of the places one can check for info; what configure.in checks for or handles and pyport.h come to mind. It would be nice to have a place that lists all the places one can check for C functionality that are not in the Python/C API directly. If people have other places in the code that one should check please let me know so I can make sure it makes it into the doc and prevents me from having to come up with another Brett Newbie Question. =)

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.

What does happen if a HAVE_foo is actually required? Does the build fail or will configure halt and say that the build will fail if you proceed? And if no one objects I will mention that looking in pyconfig.h.in is a good place to look to see what C functions that are non-POSIX and non-ANSI C we check for and pyport.h has helpful stuff as well. -Brett

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

"Brett C." writes:

Shows how much I know; I found that last night but since it didn't say POSIX anywhere I thought it was part of another standard. I guess the "Issue 5" mention means that BASE is POSIX? Or is IEEE 1003.1 basically POSIX?

In the past, the various standards different slightly. Today, IEEE 1003.1 is the same as ISO/IEC 9945:2003 (parts 1..4), is the same as Single Unix version 3, is the same as XPG/5. It contains the OpenGroup's XBD, XSH, XCU, and XRAT documents. The UNIX product standard (which apparently hasn't been revised since '98) also covers XCURSES, XTI, and a few others; UNIX98 workstation also supports X11 and CDE.

What does happen if a HAVE_foo is actually required? Does the build fail or will configure halt and say that the build will fail if you proceed?

configure only checks for the feature. If the feature is absent, yet we use the feature without an #ifdef, the build just fails; that would be a bug. Regards, Martin