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


_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user