| 115 | | First, ''one usually wants a target to be built with properties that correspond to what the user explicitly requested!'' 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. |
| | 115 | First, ''the user usually wants a target to be built with the properties he explicitly requested, and often isn't aware of the default values of features that he didn't request.'' Currently, the explicitly-requested features are treated exactly like the defaulted ones, but the information about which ones were explicitly-requested is valuable; there's no reason to throw it out just because occasionally one ''additionally'' 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 expands the cases that Boost.Build considers unambiguous to better leverage the correspondence between explicit requests and desired requirements. |
