When combining the Python library with other packages,
or with your own 'configure'-d package, warnings like:
/home/michielu/pybuild/config.h:402: warning:
`PACKAGE_VERSION' redefined
/usr/include/python2.3/pyconfig.h:663: warning: this is
the location of the previous definition

The same goes for stuff like PACKAGE_STRING,
PACKAGE_TARNAME and PACKAGE_NAME.

It is likely that more defines like HAVE_FORK, etc, can
be duplicated.

Such configuration values should not be installed
'as-is' from the ./configure output. Instead, it is
suggested the installation preprocesses a header
configuration file and uses and installs that.

Logged In: YES 
user_id=33168

Michiel can you try the version in CVS?  I believe many of
the PACKAGE_* macros have been removed.  I don't know if
this is a problem any longer.

Logged In: YES 
user_id=35033

I checked the CVS version through the CVS browser. The
PACKAGE_ macro's are still there, but only the pyconfig.h.in
is available obviously and it features an #undef there. The
configure will likely convert that to a #define.

Anyway, the _real_ problem is not the PACKAGE_ macro's,
which happen to be identical between the Python and the
ImageMagick applications (where I submitted a similar bug
report). The _real_ problem is that the defines used in
pyconfig.h are very general, like HAVE_TERM or HAVE_THREAD.
It is likely that a package will define those macro's
itself, especially if it is a 'configure'-d package.

These macro's need to be prepended with PY_ for example.
Because most of these macro's are not needed for the include
files (if any at all ofcourse, in which case the entire file
need not be installed), I suggest that only the macro's
needed for install are duplicated in a separate file,
prefixed with PY_ and have the source code check for both
versions of the macro.

Or, alternatively, preprocess the pyconfig.h after creation
and before building (the root Makefile seems a logical
place) and convert it to a new pyconfig.h with the proper
PY_ prefix. And use these macro's exclusively in the python
code.

I fail to see the problem. HAVE_CHROOT (e.g.) is indeed generic, but so
on purpose. If some other package also defines HAVE_CHROOT, but in a
different way, then the problem is not that the names of the defines are
identical, but that the values are different, hinting at a problem
elsewhere (either Python's or that other package's autoconf must have
computed the value incorrectly).

None of the PACKAGE_ macros gets defined anymore. For the other ones,
I'll close the report as "won't fix".