| 123 | | In this case, the 2nd alternative would only be selected if ''both'' {{{<threading>multi}}} and {{{<debug-symbols>on}}} were in the explicitly-requested properties. |
| 124 | | The exact way the matching algorithm should be changed to handle this capability, and especially what it would do with multiple slash-separated elements in the requirements, is a topic for discussion and research. We may decide it isn't important to handle this case, so it's not worth investing in a solution at this point. |
| 125 | | |
| | 123 | In this case, the 2nd alternative would only be selected if ''both'' {{{<threading>multi}}} and {{{<debug-symbols>on}}} were in the explicitly-requested properties. It would probably make sense to weight matches to these alternatives more heavily. A reasonable way of scoring that accounts for these [http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/bbv2/reference.html#bbv2.reference.features property paths] might be: |
| | 124 | |
| | 125 | Sum( for all matching property paths ''p'', 10^''s''(''p'')^ ) |
| | 126 | |
| | 127 | where |
| | 128 | |
| | 129 | ''s''(''p'') :== the number of slashes in ''p'' |
| | 130 | |
| | 131 | This syntax would also be more consistent with the way compound build requests are specified on the command line: |
| | 132 | {{{ |
| | 133 | bjam toolset=gcc-3.4.5/debug-symbols=on toolset=intel/optimization=off |
| | 134 | }}} |
