On Tue, Sep 8, 2009 at 3:15 PM, Matt Chambers <matthew.chambers@vanderbilt.edu> 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.