Changes between Version 5 and Version 6 of AlternativeSelection

Timestamp:

Mar 26, 2007, 4:19:40 AM (19 years ago)

Author:

Dave Abrahams

Comment:

--

AlternativeSelection

@@ -40 +40 @@
 I know at this point you're probably saying "that makes sense; you asked for something for which there's no alternative with matching requirements."  However, "no matching requirements" is currently ''not'' an error when there's only one alternative declared:
 
+===== Example 2 =====
 {{{
+# b and c both have only one alternative. 
 lib b : b.cpp : <debug-symbols>off ;
 lib c : c.cpp : <debug-symbols>on <profiling>on ;
@@ -47 +49 @@
 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 default for {{{profiling}}}, which is added to the build request, contradicts the requirements for {{{c}}}.
 
-Indeed, the error message didn't say "there's no matching alternative;" it said there's "no ''best'' alternative."  This proposal turns on how we define "best."
+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" ====
+
+Indeed, the error message didn't say "there's no matching alternative;" it said there's "no ''best'' alternative."  Whether or not we accept this proposal turns on how we define "best."  I propose that in example 1, the fact that alternative 2 matches an ''explicitly specified'' build property should make it "better" than alternative 1.
+
+