Changes between Version 21 and Version 22 of AlternativeSelection

Timestamp:

Apr 14, 2007, 12:36:23 PM (19 years ago)

Author:

Dave Abrahams

Comment:

--

AlternativeSelection

@@ -111 +111 @@
 == Why Not Separate Alternative Selection Criteria from Requirements? ==
 
-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.
+One might try to address these cases by asking the user to specify their criteria for selecting alternatives separately from their build requirements.  That would be a bad idea, for two reasons.
 
-'''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.
+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.
+
+Secondly, with alternative selection criteria completely separated from requirements, to express the same thing as one could express with two alternatives in this proposal:
+
+  lib foo : foo.cpp ;
+
+  lib foo : bar.cpp : <feature,,1,,>value,,1,, <feature,,2,,>value,,2,, ... <feature,,N,,>value,,N,, ;
+
+would take N! (yes, that's N factorial) alternatives. 
+
+'''Note:'''  I concede 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.
 
 == Details of Proposed Semantics ==