On Thu, Mar 30, 2017 at 5:35 PM, Tom Kent <lists@teeks99.com> wrote:
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


Nevermind, there is no regression vs. 1.63 here, the problem was in my user-config.jam file (how many times has that happened!). 

For both the python 2 and 3 configs, I had a 32-bit rule that included the conditions section:
: <address-model>32 <address-model> # conditions 
The goal here was to support both builds with address-model=32 and no address-model specifier. On 1.64.0.beta.2 this causes it to not find any python version and fail silently. On 1.63 it shows up as an error because python couldn't detect a suitable version.
For my build script I simply removed the conditions, so if the address-model isn't "64" then it will use that version...this works, but I had be lead to believe that the original line would work as well. Another thing that *doesn't* work is having two separate configs for the same version (for a total of three when including 64 bit) with one specifying <address-model>32 and another with no conditions. This caused an immediate error that prevented the build.

This clearly isn't a show-stopper, but it seems like it should be cleaned up....not sure how.

Tom