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

---------- Forwarded message ----------
From: Tom Kent <lists@teeks99.com>
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@lists.boost.org>




On Wed, Mar 29, 2017 at 3:59 AM, Sophonet via Boost-build <boost-build@lists.boost.org> 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