If Python is installed with architecture-dependent and architecture-independent files in separate locations (using --prefix and --exec-prefix), then config.h is placed in a directory different than Python.h (and pyport.h and pgenheaders.h, which also #include "config.h").

If I build a python module which has its own config.h (like pygtk), the build fails because Python.h #include's the *wrong* config.h. I cannot easily change the order of the
-I flags when compiling pygtk because autoconf places its flags (AM_CPPFLAGS) before any CPPFLAGS that I define in the CPPFLAGS environment variable.

It would be cleaner to follow the glib model which names its installed arch-specific file "glibconfig.h". We could install config.h as pythonconfig.h, and have Python.h #include "pythonconfig.h"

Good idea!  Patch anybody?

Assigned to Thomas.  Reassign to someone else if you don't want it!  Guido said he did want it, but didn't bother assigning it to anyone.  Given that we delayed "in dict", we have to find some other way to justify giving you a free alpha release <wink>.

I'll do it, but I don't mind if anyone else does it before me (One free alpha is enough, anyway :-) My main question is: should anybody be (legitimately) including Python's config.h directly ? I was thinking 'py_acconfig.h' myself, for the new autoconf config.h name. 

Logged In: YES 
user_id=21627

A fix for that problem has been submitted as
http://sourceforge.net/tracker/index.php?func=detail&aid=411138&group_id=5470&atid=305470

Logged In: YES 
user_id=21627

As for legitimately including config.h: it is normally
included indirectly, as a result of
AC_CHECK_HEADER(Python.h) or the like. configure will add it
the project's config.h, which might confuse the further
configuration process or have arbitrary other strange
effects.

Logged In: YES 
user_id=21627

Fixed with patch  #411138, for Python 2.2.