Linker error when doing MSVC debug builds

[Markus Ewald]

No this is not a cry for help :)
I've got a little comment about the MSVC build setup:

First, note that it is absolutely legal for a win32 project to compile 
in debug mode and link release libraries (if the intentioned is not to 
debug the specific library).
As an example, I think noone outside Microsoft has ever possessed debug 
builds of user32.lib or kernel32.lib, yet everyone is compiling his 
debug projects with those :)


The windows setup program only contains python22.lib
However, if you do a debug build of your project (and _DEBUG is defined) 
pyconfig.h tries to link python22_d.lib, resulting in a linker error.

This leads to another problem:
To avoid modifying pyconfig.h, most people would simply rename/copy 
python22.lib to python22_d.lib.

Result: _DEBUG enables Py_DEBUG enables Py_TRACE_REFS which then
           uses the _Py_DeAlloc() function instead of the same-named
           macro. _Py_DeAlloc() is not exported in the release build
           of Python22.lib.
           -> Unresolved external symbol __imp___Py_DeAlloc()

           I guess there were already one or two newbies asking
           why they got unresolved externals while they
           obviously linked python22(_d).lib in their projects ;)


Solutions: -Do not define Py_DEBUG when _DEBUG is defined
               Requires anyone who wants to debug python code to
               manually #define Py_DEBUG in his projects.

              -Export _Py_DeAlloc() in Release mode as well
               Also done in STLport, where stldebug support can
               be used in release mode as well.

              -Use an ugly hack when including Python.h:
               #ifdef _DEBUG
                 #undef _DEBUG
                 #include <Python.h>
                 #define _DEBUG
               #else
                 #include <Python.h>
               #endif
               ...no words needed.


Thx,
-Markus-