Changes between Version 4 and Version 5 of AlternativeSelection

Timestamp:

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

Author:

Dave Abrahams

Comment:

--

AlternativeSelection

@@ -34 +34 @@
 My claim is that it would be more appropriate to build the 2nd alternative because it is a better match for the explicit build request.
 
-Boost.Build generates an error because the default value of the {{{<profiling>}}} feature is {{{off}}}.  It combines that default value with the explicit build request to get {{{<debug-symbols>on <profiling>off}}}, which does not match the 2nd alternative.
+Boost.Build generates an error because the default value of the {{{<profiling>}}} feature is "{{{off}}}".  Boost.Build combines that default value with the explicit build request to get {{{<debug-symbols>on <profiling>off}}}, which does not match the 2nd alternative. 
+
+==== Consistency ====
+
+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:
+
+{{{
+lib b : b.cpp : <debug-symbols>off ;
+lib c : c.cpp : <debug-symbols>on <profiling>on ;
+}}}
+
+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."