From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-12 04:53:53
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)
And CYGWIN_PYTHON_ROOT is initialized like this:
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
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?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk