| 109 | | This is not only inconvenient, but counterintuitive and uses a syntax that is not widely known (is it even documented?). Under my proposal, the intended version of Python would've been selected. |
| | 109 | This is not only inconvenient, but counterintuitive and uses a syntax that is not widely known (is it even documented?). Under my proposal, the intended version of Python would've been selected. |
| | 110 | |
| | 111 | == Why Not Separate Alternative Selection Criteria from Requirements? == |
| | 112 | |
| | 113 | The criteria for alternative selection should not be entirely separated from build requirements for one simple reason: ''usually one wants a target to be built with properties that correspond to the build request!'' There's no reason to throw out that useful information just because occasionally one wants properties that aren't in the build request. Certainly, when the build request turns out to match an alternative's requirements exactly, Boost.Build currently considers that to be unambiguous, and that has not caused any real difficulty. This proposal is about expanding the cases that Boost.Build considers unambiguous, to better leverage the usual correspondence between requirements and build requests. |
| | 114 | |
| | 115 | '''Note:''' I admit that there are a few interesting cases one can't express today because Boost.Build doesn't allow one to separately specify alternative selection criteria, like an alternative that must be built with intel C++ when the requested toolset is msvc. However, these cases are at best very unusual; if they do need to be accomodated, a separate feature is warranted, and there's no reason not to make the usual cases work concisely. |
