alternative selection and unrelated requirements

[ghost]

The following does not work:

project
    : requirements <threading>multi
    ;

lib test : : <name>test <toolset>gcc ;
lib test : : <name>test.lib <toolset>msvc ;

The problem that requirements on the alternatives include <threading>multi, which is not really related to the alternative selection, but confuses alternative selection.

More specifically, alternative selections considers only alternatives for which all requirements are in build request. So, for single threaded build, <threading>multi is not in build request and neither alternative is selected.

What we need is an explicit selection mechanism:

lib test : : <name>test : when <toolset>gcc ;
lib test : : <name>test.lib : when <toolset>msvc ;

Or something like that.

[Dave Abrahams]

I don't understand what "does not work" about this, or what you think the author intended it to do in this case. It seems like the current logic you describe is reasonable; . Let me guess:

• the current behavior is to refuse to build either target alternative unless <threading>multi is in the build request?
• you would like <threading>multi to be added to the build properties instead, just as it would be if test were a single target with <threading>multi in its requirements?

[ghost]

Yes, the current behaviour is to refuse to build either target alternative unless <threading>multi is in the build request and yes, <threading>multi is supposed to be added to build properties.