Re: problems with python24_d.lib

> Nitro wrote:
>>> This seems to work great.  The only change I made was to use %runtime %{
>>> ... %} to insert the code because that causes this to appear earlier in
>>> the generated code (otherwise is comes after "#include <stdexcept>",
>>> which may or may not matter).
>>>    
>>
>> Won't that approach strip the _DEBUG symbol away from too many headers?  
>> For example if you #include "myHeader.h" and this header does something  
>> like #ifdef _DEBUG somewhere, then this won't work all of a sudden. Can  
>> you still debug through the wrappers (with symbol information and such) if  
>> _DEBUG is not defined for the parts except python?
>>
>> -Matthias
>>  
> It might -- here's how it gets generated ("..." means lots of stuff
> I'm skipping):
>
> ...
> #include <Python.h>
> ...
> #include <string.h>
> ...
> #include <Python.h>
> ...
> #ifdef REALLY_DEBUG
> #    define _DEBUG
> #endif
> ...
> (everything else)
>
> I don't know why Python.h is included twice (maybe the preprocessor
> makes sure only one of those is used -- I didn't look into it).  But
> string.h is the only other header that gets included before _DEBUG is
> #defined (it's included automatically by SWIG -- everything I specify
> in my .i file comes later).  However, everything compiles without
> errors or warnings (in VS 2003 -- I haven't tested this approach with
> 2005 yet) and I have successfully been able to set breakpoints and
> step through the generated code, which is what I was after.  There may
> be a pitfall in this approach, but I haven't stumbled across it yet
> (then again, you specifically mentioned VS 2005 as being problematic,
> so I'll be testing that this afternoon).
>
> Bob