diff --git a/doc/v2/faq.html b/doc/v2/faq.html index e78ce612..cc1df0b9 100644 --- a/doc/v2/faq.html +++ b/doc/v2/faq.html @@ -37,6 +37,8 @@
Greg Burley gives the following answer for Unix GCC users: + +
+Once you have created a boost python extension for your c++ library or +class, you may need to debug the code. Afterall this is one of the +reasons for wrapping the library in python. An expected side-effect or +benefit of using BPL is that debugging should be isolated to the c++ +library that is under test, given that python code is minimal and +boost::python either works or it doesn't. (ie. While errors can occur +when the wrapping method is invalid, most errors are caught by the +compiler ;-). + ++ ++ +The basic steps required to initiate a gdb session to debug a c++ +library via python are shown here. Note, however that you should start +the gdb session in the directory that contains your BPL my_ext.so +module. + + +
+(gdb) target exec python +(gdb) run + >>> from my_ext import * + >>> [C-c] +(gdb) break MyClass::MyBuggyFunction +(gdb) cont + >>> pyobj = MyClass() + >>> pyobj.MyBuggyFunction() +Breakpoint 1, MyClass::MyBuggyFunction ... +Current language: auto; currently c++ +(gdb) do debugging stuff ++
+
+Greg's approach works even better using Emacs'
+"gdb" command, since it will show you each line
+of source as you step through it.
+
+
+ +On Windows, my favorite debugging solution is the debugger that comes +with Microsoft Visual C++ 7. This debugger seems to work with code +generated by all versions of Microsoft and Metrowerks toolsets; it's +rock solid and "just works" without requiring any special +tricks from the user. + +
+ +Unfortunately for Cygwin and MinGW users, as of this writing gdb on +Windows has a very hard time dealing with shared libraries, which +could make Greg's approach next to useless for you. My best advice for +you is to use Metrowerks C++ for compiler conformance and Microsoft +Visual Studio as a debugger when you need one. + +
boost-python-runtest rule, you can ask it to launch your
+debugger for you by adding "-sPYTHON_LAUNCH=debugger"
+to your bjam command-line:
+
++bjam -sTOOLS=metrowerks "-sPYTHON_LAUNCH=devenv /debugexe" test +bjam -sTOOLS=gcc -sPYTHON_LAUNCH=gdb test ++ +It can also be extremely useful to add the
-d+2 option
+when you run your test, because Boost.Build will then show you the
+exact commands it uses to invoke it. This will invariably involve
+setting up PYTHONPATH and other important environment variables such
+as LD_LIBRARY_PATH which may be needed by your debugger in order to
+get things to work right.
+
Revised - 13 November, 2002 + 23 November, 2002