Boost.Python V1 questions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-12 04:53:53

Dave,
since Boost.Python support is among the few things missing from V2, I'm now 
looking at the logic used by v1 to detect python installation locations, and 
thinking how it could work in V2.

First, what should the initialization interface be. One possibility:

# Tries to find the Python root
using python ; 
# Specifies everything manually
using python : /usr/include/python2.2 ........... ; 

Another approach is to allow several Python versions:

using python : 2.2 : .......... ;

is this needed, in your opinion?

Secondly, I'm a bit confused with CYGWIN/NT handling in v1. First, it is true 
that only cygwin version of gcc is supported? And that cygwin gcc must be 
also invoked in cygwin shell? Here's the relevant code:

rule select-nt-python-includes ( toolset variant : properties * )
{
if $(toolset) in $(gcc-compilers)
{
........
properties += 
<sysinclude>$(CYGWIN_PYTHON_$(d)ROOT)/include/python$(CYGWIN_PYTHON_$(d)VERSION) ;

And CYGWIN_PYTHON_ROOT is initialized like this:

if $(PYTHON_WINDOWS)
{
CYGWIN_PYTHON_ROOT ?= /usr ;

So, if you're using gcc + msvc on NT, the logic will try using "/usr" as 
python root for gcc and c:/tools/python for msvc, which is a bit strange. 
Actually, why we need *both* CYGWIN_PYTHON_ROOT and PYTHON_ROOT, and use the 
first for gcc and the second for other compilers. Is it possible to detect 
one Python location and use it for all toolsets? What are the problems with 
that?

Another question is about python debug mode.

CYGWIN_PYTHON_DEBUG_ROOT ?= /usr/local/pydebug ;

Am I right that cygwin python uses different roots for debug and release 
version, while for NT python, we have only different libraries? Could you 
explain why it's so?

- Volodya