Re: [Boost-build] Defining variant with toolset version

Subject: Re: [Boost-build] Defining variant with toolset version
From: Johan Larsson (hnefi.mail_at_[hidden])
Date: 2009-09-08 10:03:21

On Tue, Sep 8, 2009 at 3:15 PM, Matt Chambers <
matthew.chambers_at_[hidden]> wrote:

> Hi Johan,
>
> Johan Larsson wrote:
>
>> So I tried defining a set of variants, like so:
>> variant v0 : <debug-symbols>on <optimization>space <inlining>off
>> <threading>multi <toolset>gcc ;
>> variant v1 : v0 : <toolset>gcc-A ;
>> variant v2 : v0 : <toolset>gcc-B ;
>> variant v3 : v2 : ;
>>
>> The problem:
>> When I try to build a specific variant, say v1, it builds not only for
>> gcc-A, but also gcc-B. Likewise, v2 and v3 builds with both toolsets. What I
>> want is for v1 to only invoke gcc-A, v2 only to invoke gcc-B, etc.
>>
>> Is there a good way to achieve the desired behaviour?
>>
>
> Is there a particular reason you want to do this with variants instead of
> defining your own custom composite feature? I would expect that you'd want
> to keep the release/debug/profiling concept orthogonal to the toolset
> concept. It also looks like you're composing v1-2 on top of v0, so v1 has
> both gcc and gcc-A, v2 has both gcc and gcc-B, and v0 and v3 just have gcc.
> So I suspect that's why it's building with multiple toolsets.
>
> -Matt
>
> (I hope this message isn't deformed; I'm more used to forums than mailing
lists)

Thank you for your reply. The reason I'm using variants is that on first
glance, they seem to correspond well to Make targets. I want to be able to
invoke bjam and build one specific variant, or several, or all. I also want
the finished binaries etc to be distributed to different tree hierarchies
for each variant. Perhaps this could be done with composite features as
well? I'll try it.

I have no need for release, debug etc builds; that sort of distinction is
not meaningful in this project due to the constraints of the target hardware
and the amount of time it would take to build multiple variants for each
real hardware target. For me, a variant corresponds most closely to a
hardware configuration, and each hardware configuration uses one of three
toolsets.

This one-to-many relationship is important for me to represent in the build
system in an intuitive and maintainable way; I need to allow the users of
the build system to specify only a hardware target (variant) and have the
build system deduce the correct toolset, build options, dist location,
install routines etc etc. Internally, however, most (but not all) of the
build routines are shared within one group of variants that use the same
toolset. This makes it wonderfully convenient to define includes, defines
etc in bjam in terms of toolset if I can associate a toolset with a variant.
It would save an immense amount of work.

Anyway, the problem still exists even if <toolset>gcc is removed from the
definition of v0. Note that v1 builds with the toolset version specifically
defined for v2, NOT the version defined for v0. In other words, with the
definitions in my original post, v1 builds with gcc-A and gcc-B, but not
plain gcc. It should build with only gcc-A. v1 is not descended from any
variant containing gcc-B.