Subject: Re: [Boost-build] selecting Python version for Boost.Python
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-02-06 20:25:08
On 02/06/2018 12:46 PM, Stefan Seefeld via Boost-build wrote:
> On 06.02.2018 14:30, Steven Watanabe via Boost-build wrote:
>> The normal b2 rules are:
>> - The first version specified is the default, which will
>> be used if no version is given explicitly.
> So for those "normal" cases, where is a) the list of specified versions
It's a global list in the feature module:
toolsets = [ feature.get-values <toolset> ] ;
new values are added by feature.extend.
> b) the selected version stored ?
The selected version is stored in a property-set
which is passed as a parameter through all the
internal machinery of Boost.Build.
If you build multiple versions, it will just
cause Boost.Build to run main-target.generate
with each property-set in turn.
> (I see the `toolset` variable (feature) holds the full list. Where is
> the actual selection stored if I run `b2 toolset=gcc` ?)
> >> - If one or more versions are specified on the
>> command line, then exactly those versions will be built.
> That corresponds to my expectation.
>> - All versions used must be initialized in user-config.jam
>> (or another configuration file).
> Can you elaborate ? What about default versions ? What if I have an
> empty `user-config.jam` file ? "gcc" will still be found, even if I
> don't explicitly initialize it in any configuration file. Or is there
> anywhere a list of explicit gcc versions that are supported ?
toolset gets special case handling in the
core of Boost.Build. IIRC, python's Jamfile
if ! [ python.configured ]
using python ;
which sets up a default. (Boost.Build doesn't
actually care whether `using` is in a configuration
file or a Jamfile. user-config.jam is essentially
a standalone Jamfile which gets loaded before anything
>> Python does not conform to this. It only supports one
>> version of python 2 and one version of python 3 which
>> are determined solely by the configuration files and
>> cannot be overridden on the command line.
> That's exactly what I'd like to fix. In fact, there are multiple issues
> I'd like to fix, but to do that I need to understand what behaviour
> would be consistent with the rest of b2.
> Here are the issues I want to address:
> * `b2 python=<N>` doesn't have any effect, when it really should pick a
> single python version
> * the current logic builds at most two versions, as you say: at most one
> python 2 and one python 3 version. For consistency we should build as
> many versions as are selected
> * a requirement for the last point: instead of just appending '3' to the
> library name iff it's built with Python 3, the real Python version, i.e.
> <major><minor> (without the dot) should be appended.
The way to do this is to change the <tag> rule to append
the version to the name instead of creating separate
targets for python2 and python3. This change should
fix all of the above.
> Where is the looping over all (selected) toolsets being implemented ?
It's implemented in two different places:
- build-system.jam processes the command line
arguments into a list of property-sets.
- A main-target (targets.jam) can specify multiple
values of a property in its default-build.
> And what would be the right location to add the equivalent looping over
> Python versions ? (I'm now hacking something together within the
> Boost.Python Jamfile. But that's far from ideal as I need similar loops
> for the tests...)
You don't need an explicit loop. Boost.Build can manage it
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk