Re: [jamboost] Re: Boost.Python V1 questions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-13 04:48:39

On Saturday 13 November 2004 05:26, David Abrahams wrote:

> > # Tries to find the Python root
> > using python ;
> > # Specifies everything manually
> > using python : /usr/include/python2.2 ........... ;
>
> Looks good to me.
>
> > Another approach is to allow several Python versions:
> >
> > using python : 2.2 : .......... ;
> >
> > is this needed, in your opinion?
>
> It's needed for people like me who want to be able to test against
> multiple Python versions.

Ok. Is "python-version" property OK with you? So that it's possible to write:

bjam python-version=2.2 python-version=2.3

?

> > Secondly, I'm a bit confused with CYGWIN/NT handling in v1. First,
> > it is true that only cygwin version of gcc is supported?
>
> When targeting Cygwin, yes. When targeting NT you can use mingw or,
> I suppose, gcc-nocygwin.

I now see that 'gcc-compilers' are computed like this:

gcc-compilers = [ MATCH ^(gcc.*)$ : $(TOOLS) ] ;
mingw-compilers = [ MATCH ^(mingw.*)$ ^(gcc-nocygwin.*) : $(TOOLS) ] ;
gcc-compilers = [ difference $(gcc-compilers) : $(mingw-compilers) ] ;

so that does not include gcc targeting NT.

> > And that cygwin gcc must be also invoked in cygwin shell?
>
> I'm not sure what you mean. bjam invokes cygwin gcc. Do you mean
> that bjam must be invoked under the cygwin shell? That's not true;
> you can build and test for cygwin gcc under an NT shell. I did that
> in part so I could test for cygwin and windows with a single bjam
> invocation.

So when running bjam in NT, you'll specify "/usr" for CYGWIN_PYTHON_ROOT and 
that will eventually be passed to cygwin gcc -- which can understand the 
"/usr" syntax. And NT bjam never does anything with "/usr" which requires 
filesystem access? I was confused by the fast that NT bjam can use cygwin 
paths.

> > 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.
>
> It's intentional. When using gcc in its cygwin mode you need to find
> the cygwin installation of Python.

So, when manually initializing python we need either to pass two paths:

using python : 2.3 : c:/python /usr/python ;

or allow to specify specific properties in initialization:

using python : 2.3 : c:/python ;
using python : 2.3 : c:/python : <toolset>gcc <toolset-flavour>cygwin ;

> > Is it possible to detect
> > one Python location and use it for all toolsets?
> > What are the problems with that?
>
> Cygwin Python is essentially a Unix build; Windows Python is a Win32
> build. They're different and require different treatment.

Understood.

> > Am I right that cygwin python uses different roots for debug and release
> > version
>
> Yes.
>
> > while for NT python, we have only different libraries?
>
> Right.
>
> > Could you explain why it's so?
>
> You'd have to ask the Python developers why.

If that's the way Python works, I'll just live with that.

Thanks,
Volodya