******************************************************************** *** The Boost release has been waiting on this; I would *really* *** *** appreciate it if people would take a little time to test it. *** ******************************************************************** I've just checked into the RC_1_34_0 branch most of the support for building and testing Python extensions and Boost.Python in BBv2. It took me over a week, and it's almost completely revamped. In case you're wondering, yes, it was necessary. Support for Windows, Darwin, and Cygwin was essentially nonexistent or broken. If it was working for you on any of these platforms, you were probably getting "lucky." I would appreciate it if those who can test this would invoke bjam with --debug-configuration, and look at the output to make sure the python configuration stuff looks sensible. Here's the new comment on python.init: # Initializes the Python toolset. Note that all parameters are # optional. # # - version -- the version of Python to use. Should be in Major.Minor # format, for example 2.3. Do not include the subminor version. # # - cmd-or-prefix: Preferably, a command that invokes a Python # interpreter. Alternatively, the installation prefix for Python # libraries and includes. If empty, will be guessed from the # version, the platform's installation patterns, and the python # executables that can be found in PATH. # # - includes: the include path to Python headers. If empty, will be # guessed. # # - libraries: the path to Python library binaries. If empty, will be # guessed. On MacOS/Darwin, you can also pass the path of the # Python framework. # # - condition: if specified, should be a set of properties that are # matched against the build configuration when Boost.Build selects a # Python configuration to use. # # Example usage: # # using python : 2.3 ; # using python : 2.3 : /usr/local/bin/python ; # You can set up your user-config.jam so a bjam built under Windows will can build/test both windows and cygwin python extensions. Just pass <target-os>cygwin in the "condition" parameter to "using python..." for the cygwin python installation. using python ; # windows installation using python : : /usr/bin/python2.5 : : : <target-os>cygwin ; when you put target-os=cygwin in your build request, it should build with the cygwin version of python: bjam target-os=cygwin toolset=gcc This is supposed to work the other way, too (targeting windows python with a cygwin bjam) but it seems as though the code in the compiler toolsets for building that way is broken (i.e., it's not a python-specific problem). What's still broken =================== 1. When targeting Cygwin, PYTHONPATH setup information is not properly passed from Python extension targets to test targets, because the information is getting attached to an import library (one we don't even need to generate) instead of the shared library. This affects one test (builtin_converters) in the Boost.Python test suite. We're waiting on Vladimir Prus to fix that one. I hope he'll be able to do that in the next few days. 2. There's no support for debug-python builds (the ones that require the trailing "_d" in the executable and extension module names -- see http://boost.org/libs/python/doc/building.html#variants). I think I can implement that tomorrow. If you got this far in the message, thank you *very* much for your attention :) -- Dave Abrahams Boost Consulting www.boost-consulting.com