Boost logo

Boost-Build :

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


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.
- If one or more versions are specified on the
  command line, then exactly those versions will be built.
- All versions used must be initialized in user-config.jam
  (or another configuration file).

  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.

In Christ,
Steven Watanabe


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