Opened 18 years ago
Last modified 17 years ago
#16 new defect
alternative selection and unrelated requirements
Reported by: | ghost | Owned by: | somebody |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | component1 | Version: | |
Keywords: | Cc: |
Description
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.
Change History (5)
comment:1 Changed 18 years ago by
Milestone: | → M12 |
---|
comment:2 Changed 17 years ago by
Milestone: | M12 → M13 |
---|
comment:3 Changed 17 years ago by
comment:4 Changed 17 years ago by
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.
comment:5 Changed 17 years ago by
Milestone: | M13 |
---|
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:
<threading>multi
is in the build request?<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?