Re: [Boost-build] Building Boost with multiple python versions

Subject: Re: [Boost-build] Building Boost with multiple python versions
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-02-15 17:13:36

On 15.02.2017 12:00, Rene Rivera wrote:
> On Wed, Feb 15, 2017 at 10:50 AM, Stefan Seefeld <stefan_at_[hidden]
> <mailto:stefan_at_[hidden]>> wrote:
>
>     On 15.02.2017 11:39, Rene Rivera wrote:
>     >
>     > You can specify multiple features in the command like to
>     indicate the
>     > collective requirement request of what you want to build. Hence
>     if you
>     > configure the python interpreter with conditions that match that
>     build
>     > request it should use that interpreter only. That's assuming it
>     wasn't
>     > broken though :-(
>
>     OK. But all existing bugs in the implementation aside, I think this is
>     more of a UI concern: If I understand correctly, the "python" feature
>     expects values that express versions (so I can select a python
>     config on
>     the command line with "<python>2.7".
>     my question is about what happens if the version alone isn't an
>     unambiguous discriminator, i.e. if I need to distinguish between a
>     64-bit python and a 32-bit python, both using the same version 2.7
>     ? How
>     can I express that, both on the command line as well as in my
>     user-config.jam configuration with the `using` rule ?
>
>
> Given Tom's example user-config you can: 
>
> b2 python=2.7 address-model=32
> b2 python=2.7 address-model=64
> b2 python=3.5 address-model=32
> b2 python=3.5 address-model=64
>
> To build them individually. And if you plan on installing you'd have
> to install to different locations as address-model doesn't tag the
> built products. You can also build multiple combinations in one go with:
>
> b2 python=2.7,3.5 address-model=32
> b2 python=2.7,3.5 address-model=64
>
> Or all the combinations with:
>
> b2 python=2.7,3.5 address-model=32,64

Hmm, I'm not entirely convinced that means the same thing. The
"address-model" is a separate feature here, while what I had in mind was
more a composite feature (with 'version' and 'address-model' being
constituents). For this particular example this may not matter, as
address-models can't be mixed (or can they ?).

But consider the other part: defining python configurations:

using python : 2.7 : .... ;

defines a python "tool" with a "version" feature "2.7". There doesn't
appear to be a way to attach an address-model feature to it. So it's
impossible to express "here is a python configuration for which the
"version" is X.Y and the "address-model" is Z", and neither is there a
way to request a python configuration (such as done via "using python :
2.7") with both version and address-model fixed.

The "using ..." rule can be used both as a definition of a tool as well
as to request one. So it seems it might be useful to add an
"address-model" (optional) argument to the python.init() function (and
by extension, the `using python ...` rule.

>
> I believe the general build request option syntax is documented. But I
> leave finding that doc as an exercise for the reader ;-)

Hah. :-)

But to fully drive home my point, I think this entire discussion reveals
not so much shortcomings in the implementation but issues on the
conceptual level (and holes in the documentation), don't you think ?

Thanks,
        Stefan

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