James Mastro wrote:
>  Hello list. I've been using wxWidgets for awhile, decided to give 
>  wxPython a try. So far I'm really impressed and would move my app over 
>  to wxPython asap, except for one concern.
>  
>  The project I'm working on is an application that uses a couple of 
>  static libraries written in C++ that I've used Boost.Python on to allow 
>  their use from Python. I'm developing these libraries along with the 
>  app. In other words, I really need to be able to debug them, step 
>  through the code, etc. I'm not sure how I would be able to do this if 
>  I'm using wxPython. Maybe with gdb? Is there any way to use MSVC for 
>  debugging?
>  

It's not as easy as debugging a normal application, but it is possible. 
  There may be other ways, but this is what I do to debug the wxPython 
extension modules:

* Build a debug version of Python.  This will result in python_d.exe and 
"_d" versions of the Python DLL and the core extension modules.  You 
won't be able to build all of the stock extension modules unless you get 
some 3rd party sources and build those too, but if you don't need them 
in your app there is no need to worry about them.  The reason that the 
"_d" is used is because different versions of the C Runtime Lib DLLs are 
used between the debug and release build.

* I manually "install" the _d versions of everything in the same install 
tree as the stock Python, but you can probably run them in place if you 
want.

* You'll need to also make debug versions of wxWidgets and wxPython. 
Follow the instructions in wxPython/docs/BUILD.txt.

* Build a debug version of your extension modules.

* Make a new project in MSVC using the "Makefile" template.  Since I use 
makefiles and distutils for the builds this MSVC project is used only 
for debugging.  In the Project Settings, on the Debug tab, set it to run 
python_d.exe and give your main .py file as the program args.  In the 
Additional DLLs section add any *.dll's and *_d.pyd's that you would 
like to be able to set breakpoints in.  The debug symbols for the files 
in this list will be preloaded when you run the app so it knows where to 
set the breakpoints.  If they're not preloaded then it will disable 
those breakpoints when you start and then you have to renable them after 
the python modules have been loaded.

* Set a breakpoint where desired in your extension module and then run 
the app in the debugger.  You can also use wx.Trap() in your Python code 
to cause a breakpoint if you want.


BTW, if you only want to be able to debug your own extension module then 
you can avoid most of the above, and just use the release mode Python, 
wxPython, etc.  You just need to be sure that your debug build for your 
extension module does *not* use the debug version of the C Runtime Lib 
DLL.  However if you debug this way you won't be able to trace through 
any of the wx or Python code, and you won't be able to have a full stack 
trace, etc.  IMO, those are worth the extra effort.


When on Linux or OSX I use a different approach.  I add code like this 
to the main module of the app, right after it does import wx:

	print "pid:", os.getpid()
	raw_input("Press Enter...")

Then when I run the app it prints the PID and I can use the attach 
command in gdb to attach to the process, and since the wx module has 
been imported then all the code I'm interested in has been loaded and 
the debugging symbols are available.  I'm then able to set breakpoints 
as needed and "continue", then I hit Enter in the terminal where the app 
is running and off it goes.


-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!


---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@[...].org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org