Re: [Boost-build] selecting Python version for Boost.Python

Subject: Re: [Boost-build] selecting Python version for Boost.Python
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-02-06 20:25:08

AMDG

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:
>> <snip>
>> 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
> and

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
has

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
else.)

>>   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
for you.

In Christ,
Steven Watanabe