Changes between Version 10 and Version 11 of AlternativeSelection

Timestamp:

Mar 26, 2007, 6:14:57 AM (19 years ago)

Author:

Dave Abrahams

Comment:

--

AlternativeSelection

@@ -47 +47 @@
 }}}
 
-in this case, {{{bjam debug-symbols=on}}} happily builds both {{{b}}} (with debug-symbols off) and {{{c}}} (with profiling on) despite the fact that the requirements for {{{b}}} directly contradict the explicit build request and that the requirements for {{{c}}} contradicts the default for {{{profiling}}}, which is implicit.
+in this case, {{{bjam debug-symbols=on}}} happily builds both {{{b}}} (with debug-symbols off) and {{{c}}} (with profiling on) despite the fact that the requirements for {{{b}}} directly contradict the explicit build request and that the requirements for {{{c}}} contradicts the default for {{{profiling}}}, which is implicitly {{{off}}}.
 
-The behavior in example 2 may seem counterintuitive, but it is widely regarded as desirable to succeed in building something, even if it doesn't exactly match what the user asked for, than to cause an error.  I'm not challenging that premise in this proposal.  In fact, the point of this proposal is to make the case where there are multiple alternatives more consistent with that principle.
+The behavior in example 2 may seem counterintuitive, but it is widely regarded as desirable to succeed in building ''something'', even if it doesn't exactly match what the user asked for, than to cause an error.  I'm not challenging that premise in this proposal.  In fact, the point of this proposal is to make the case where there are multiple alternatives more consistent with that principle.
 
 === Definition of "Best" ===
@@ -75 +75 @@
 
 Here Boost.Build complains because the {{{<threading>single}}} is the default.  If you read ticket #16, you can see that the intended result was that Boost.Build choose the first alternative.  My proposed change would accomplish that with no change in the Jamfile.  We would lose the capability of specifying these alternatives in such a way that the build request {{{bjam toolset=gcc}}} causes an error.
+
+== Details of Proposed Semantics ==
+
+The semantics I'm proposing depend on the notion of "explicitly-requested" build properties.
+
+  '''Definition:''' a top-level target's explicitly-requested build properties are those that 
+  are specified on the command line, e.g. {{{bjam '''threading=multi'''}}}.  A dependency
+  target's explicitly-requested build properties are those that are propagated from its dependent
+  target(s).  As a special case, {{{<toolset>}}} is always considered to be explicitly requested,
+  even when not explicitly specified on the command line.
+
+When choosing among target alternatives, the one with the greatest number of requirements matching its explicitly-requested properties is selected.  An ambiguity error is only reported when two alternatives match the same number of requirements. 
+
+When searching for dependency targets, the dependent's requirements are combined with its explicitly-requested build properties to form a new set of explicitly-requested properties, to be applied to its dependencies.  During combination, where a non-free feature in the dependent's requirements conflicts with its explicitly-requested properties, the requirement is selected over the the explicitly-requested value of that feature.  
+
+== Not A Pure Extension ==
+
+
+== Optional Extension to this Proposal ==
+