On 06.02.2018 14:30, Steven Watanabe via Boost-build wrote:

AMDG

On 02/06/2018 11:47 AM, Stefan Seefeld via Boost-build wrote:

[Rene, I suppose you are the person most familiar with the Python
support in b2, so I suspect you know the answer to the below questions.
But this is also about consistency, so I'd like to extend the question
to understand how b2 deals with multiple values (such as for the
"toolset" feature) in general.]


I'm reviewing the b2 logic in `python.jam` as well as Boost.Python's
Jamfiles, and I'm not sure about the intended logic as far as multiple
Python versions are concerned:

With my `user-config.jam` file containing two `using python ...`
statements (with two distinct versions), is the intent for Boost.Python
being built for both ? Or only if the two differ in the major version
number (i.e., '2' and '3') ? And what about using "python=N" as
command-line option to `b2` ? if I set "N" to be a version string not
defined in my `user-config.jam` file, I get an error ("... is not a
known value of feature <python"). But if I give a "known value", nothing
happens, i.e. `b2` still builds both versions.

So what is the intended semantic for giving multiple python versions in
my `user-config.jam` file, and what is the intent for "python=N" on the
command line ?

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 b) the selected version stored ?
(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 ?

  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.

Where is the looping over all (selected) toolsets being implemented ? 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...)

Thanks,
Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...