Boost logo

Boost-Build :

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 ?


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

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at