Hi,

 

Apologies for the long email, but I figured I might as well be detailed in my explanation. My two questions are below regarding the process of building Boost.Python against a PY_DEBUG debug build of Python, and the failure of auto-linking of such debug libs of Boost.Python (those with  ‘gyd’ in the name).

 

I’m using both the Release and Debug versions of Python 2.5.1 on Windows compiled with Visual Studio 2005. The Debug version of python produces python_d.exe and python25_d.dll, while the release version uses python.exe and python25.dll.

 

I’ve downloaded and built Boost 1.35.0 with the following steps:

 

1. Edit Jamroot as follows:  (lines I add start with a “+” )

 

      <define>BOOST_ALL_NO_LIB=1

+     <define>_SECURE_SCL=0                                

 

I do this since our codebase is compiled without the secure iterators for performance reasons. This isn’t relevant to my question, but I might as well mention it.  Also, I add the following to build the debug python libs:

 

# location of python

local python-root = [ MATCH "^--with-python-root=(.*)" : [ modules.peek : ARGV ] ] ;

PYTHON_ROOT ?= $(python-root) ;

 

+ using python : 2.5 : C:\\3rdparty\\Python\\Python-2.5.1-vc8sp1-Patch1\\PCbuild\\python.exe                              

+   : C:\\\3rdparty\\Python\\Python-2.5.1-vc8sp1-Patch1\\Include C:\\3rdparty\\Python\\Python-2.5.1-vc8sp1-Patch1\\PC

+   : C:\\\3rdparty\\Python\\Python-2.5.1-vc8sp1-Patch1\\PCbuild                                                          

+   : <python-debugging>off ;                                                                                                  

 

 

+ using python : 2.5 : C:\\3rdparty\\Python\\Python-2.5.1-vc8sp1-Patch1\\PCbuild\\python_d.exe                           

+   : C:\\3rdparty\\Python\\Python-2.5.1-vc8sp1-Patch1\\Include C:\\3rdparty\\Python\\Python-2.5.1-vc8sp1-Patch1\\PC

+   : C:\\3rdparty\\Python\\Python-2.5.1-vc8sp1-Patch1\\PCbuild                                                          

+   : <python-debugging>on ;                                                                                                  

 

# Select the libraries to install.

 

I could also add this to my user-config.jam file but I got annoyed by bjam not picking that up if it is in the same folder as Jamroot, it would only find it if I put it in my user home.

 

Then I trigger the builds using bjam:

  bjam.exe -d +2 --toolset=msvc --build-type=complete install

  bjam.exe -d +2 --toolset=msvc --with-python python-debugging=on install debug

  bjam.exe -d +2 --toolset=msvc --with-python python-debugging=off install release

 

This gives me the complete Boost I want with the addition of the Release and Debug versions of Boost Python. The Debug version of Boost Python I’m after is boost_python-vc80-mt-gyd-1_35.dll and the release is boost_python-vc80-mt-1_35.dll

 

So, my first question is: Surely there must be an easier way to do what I tried to achieve above? Should building a true debug (ie, a traditional python debug lib with PY_DEBUG enabled) version of Boost Python really take this much hackery? This is where people point out to me just how little I know about bjam / boost build…

 

Second problem is the auto linking of.Boost Python.

If I create an DLL application in Visual Studio 2005, set the include directories, set the library directories, set the output target as BoostPythonTest.pyd in Release, and BoostPythonTest_d.pyd in Debug, I get the following situation.

 

 

#include <boost/python.hpp>

 

char const* greet()

{

  return "hello, world";

}

 

BOOST_PYTHON_MODULE(BoostPythonTest)

{

  using namespace boost::python;

  def("greet", greet);

 

 

This auto-links boost_python-vc80-mt-1_35.dll in Release mode just as it should and everything works just fine.

In Debug mode, this auto links boost_python-vc80-gd-1_35.dll which is the Boost.Python debug lib which does not define PY_DEBUG which is not the behaviour I want. The Boost Python docs makes some reference to using BOOST_DEBUG_PYTHON to change the behavior of wrap_python.hpp but no such support seems to exist to modify the auto-linking behavior.  To get my module to link to release python in release mode, and debug python via boost_python-vc80-mt-gyd-1_35.lib (with PY_DEBUG, ie python25_d.dll) in debug mode, I need to do the following:

 

#define BOOST_PYTHON_NO_LIB

 

#ifdef _DEBUG

 #define BOOST_DEBUG_PYTHON

 #pragma comment(lib, "boost_python-vc80-mt-gyd-1_35.lib" )

#else

 #pragma comment(lib, "boost_python-vc80-mt-1_35.lib" )

#endif

 

#include <boost/python.hpp>

 

char const* greet()

{

  return "hello, world";

}

 

BOOST_PYTHON_MODULE(BoostPythonTest)

{

  using namespace boost::python;

  def("greet", greet);

}

  

I’ve had a look through the auto-linking code in boost and no special case seems to exist for the debug Python libraries.

 

Once again, my question is whether this really is what I need to do to get Boost Python to play nicely with PY_DEBUG debug mode Python?

 

Thanks for any advice, or general abuse for my misunderstanding on how to configure boost build properly.

 

Brian

 

 

 

 

Ps: If you do not do this and link to boost_python-vc80-gd-1_35.lib instead you get this warning when you try to import your lib into a debug python interpreter:

 

    >>> import BoostPythonTest

    Fatal Python error: Interpreter not initialized (version mismatch?)