Changes between Version 9 and Version 10 of AlternativeSelection

Timestamp:

Mar 26, 2007, 5:49:56 AM (19 years ago)

Author:

Dave Abrahams

Comment:

--

AlternativeSelection

@@ -55 +55 @@
 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.
 
+=== Example 3 ===
 
+This example is a simplified, but equivalent, version of the example in ticket #16:
+
+{{{
+lib test : : <name>test <toolset>gcc <threading>multi ;
+lib test : : <name>test.lib <toolset>msvc <threading>multi ;
+}}}
+
+a simple "{{{bjam toolset=gcc}}}" currently yields:
+
+{{{
+error: No best alternative for ./test
+    next alternative: required properties: <threading>multi <toolset>gcc
+        not matched
+    next alternative: required properties: <threading>multi <toolset>msvc
+        not matched
+}}}
+
+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.