Re: [Boost-build] Boost.Python build (config ?) error

Subject: Re: [Boost-build] Boost.Python build (config ?) error
From: Tom Kent (lists_at_[hidden])
Date: 2017-03-30 22:35:03

My mailserver (dreamhost) was having issues, sending again.

---------- Forwarded message ----------
From: Tom Kent <lists_at_[hidden]>
Date: Thu, Mar 30, 2017 at 6:50 AM
Subject: Re: [Boost-build] Boost.Python build (config ?) error
To: "Boost.Build developer's and user's list" <boost-build_at_[hidden]>

On Wed, Mar 29, 2017 at 3:59 AM, Sophonet via Boost-build <
boost-build_at_[hidden]> wrote:

> Hi list,
>
> thanks for the correction, which partly solves the problem which I have
> more or less reported at the same time (http://lists.boost.org/boost-
> build/2017/03/29342.php).
>
> However, it is still not possible to specify a boost version in the b2
> configuration command line. Always the first entry of user-config.jam is
> selected.
>
> Example: I have python 3.5 and python 3.6 installed on my system (conda).
> My user-config.jam looks like this (note: 3.5 is first):
>
>
> using python : 3.5 : C:/Miniconda3/envs/py35/python.exe
>              : #includes
>              : #libs
>              : <address-model>64 ;
> using python : 3.6 : C:/Miniconda3/envs/py36/python.exe
>              : #includes
>              : #libs
>              : <address-model>64 ;
>
> However,
>
> b2 --build-dir=D:\build\boost_1_64_0 --prefix=D:\install\86
> address-model=64 python=3.6 --with-python variant=release
> [--debug-configuration]
>
> the given python version (which is 3.6) seems to be ignored. A snippet of
> the debug output is copied below. Note that it says "...requested
> configuration matched" for the first try (which is 3.5). The final
> boost_python dll in this example incorrectly depends on python 3.5.

I think I'm seeing a similar issue with the beta builds that I've been
building. Last night I ran the soon-to-be beta 2 build, after seeing this
thread I looked at what libraries it created and noticed that all the
32-bit builds were missing the python library.

Here's my user-config.jam:
import toolset : using ;

using python
: 2.7 # version
: # Interperter/path to dir
: D:\\ReleaseBuild\\Python27-32\\include # includes
: D:\\ReleaseBuild\\Python27-32\\libs # libs
: <address-model>32 <address-model> # conditions
;

using python
: 2.7 # version
: # Interperter/path to dir
: D:\\ReleaseBuild\\Python27-64\\include # includes
: D:\\ReleaseBuild\\Python27-64\\libs # libs
: <address-model>64 # conditions
;

using python
: 3.6 # version
: # Interperter/path to dir
: D:\\ReleaseBuild\\Python36-32\\include # includes
: D:\\ReleaseBuild\\Python36-32\\libs # libs
: <address-model>32 <address-model> # conditions
;

using python
: 3.6 # version
: # Interperter/path to dir
: D:\\ReleaseBuild\\Python36-64\\include # includes
: D:\\ReleaseBuild\\Python36-64\\libs # libs
: <address-model>64 # conditions
;

You'll notice that I have two versions of each of python 2 and 3, but they
are the same version number, the only difference is which one goes with
which address-model.

The builds appear to be fine, each one outputs the line:
    - python                   : building

There are too many warnings and such that scroll by during the build, so I
don't know if it complained about it during the build. However, I run each
build a second time immediately after, to capture errors with anything that
built and nothing shows up related to python. For 64-bit both python and
python3 libraries are generated, for 32-bit there are no python libraries.

I'm not positive, but I think this is a regression from the 1.63 release.
For that release, I only tried to build python 2, but it successfully built
for both 32 and 64 bit configurations. It could be something with my setup
here (I"ve also rolled version numbers from 2.7.5. to 2.7.13), but I'd lean
towards it being something in the build/python source.

Thoughts?
Tom