|
Boost : |
Subject: Re: [boost] [release] Boost 1.66.0 Beta 1 Release Candidate 1
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-12-09 03:18:57
On 08.12.2017 22:12, Steven Watanabe via Boost wrote:
> AMDG
>
> On 12/08/2017 08:00 PM, Stefan Seefeld via Boost wrote:
>> On 08.12.2017 21:52, Steven Watanabe via Boost wrote:
>>> <snip>
>>> import feature ;
>>> feature.feature python-version : 3 : propagated optional ;
>>>
>>> import modules ;
>>> import toolset ;
>>> # Allow command line switching
>>> if --use-python3 in [ modules.peek : ARGV ]
>>> {
>>> project : requirements <python-version>3 ;
>>> using python : 3.xx : ... ;
>>> }
>>> else
>>> {
>>> using python : 2.xx : ... ;
>>> }
>> Can you elaborate a bit on what this will achieve ? It seems this simply
>> means the same user-config.jam file can be reused for two `b2`
>> invocations (one with `--use-python3` and one without). But the build
>> logic would still need to be augmented to:
>>
>> 1) run `b2` as before
>> 2) remove the build tree for Boost.Python, i.e. everything under
>> `bin.v2/libs/python`
>> 3) rerun `b2`, this time with additional `--use-python3 --with-python`
>> arguments, to only rebuild Boost.Python, this time with Python3.
>> 4) collect all binaries from the staging area during packaging.
>>
>> Correct ?
>>
> Step (2) is not necessary. python-version is specifically
> to avoid this step, by forcing the python3 build to
> use a different build directory.
I see, thanks. What would be the "correct" fix for this, i.e. where
would this `python-version` feature have to be defined (and used) to
allow `b2` to be usable as intended, i.e. building for both, Python2 and
Python3 in a single run ?
(I take it even with this it would still not be possible to build
against two arbitrary Python versions, as the feature as it is defined
now will only distinguish between '2' and '3', rather than taking the
exact Python version into account, as it does for toolchain versions.)
Stefan
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk