= Proposal for "Do the Right Thing" Alternative Selection = This page describes a proposal for a change to the way target alternatives are selected. == Motivation == It seems there are a significant number of {{{bjam}}} invocations for which there is a sensible interpretation, but for which Boost.Build currently generates an error instead and refuses to build. === Example 1 === Given the following Jamfile: {{{ lib a : a.cpp : off ; # alternative 1 lib a : a-dbg.cpp : on on ; # alternative 2 }}} In response to {{{ bjam debug-symbols=on }}} the result is {{{ error: No best alternative for ./a next alternative: required properties: off not matched next alternative: required properties: on on not matched }}} 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 {{{}}} feature is "{{{off}}}". Boost.Build combines that default value with the explicit build request to get {{{on 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 : off ; lib c : c.cpp : on 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."