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 : <debug-symbols>off ;                   # alternative 1
lib a : a-dbg.cpp : <debug-symbols>on <profiling>on ;  # alternative 2

In response to

bjam debug-symbols=on

the result is

error: No best alternative for ./a
    next alternative: required properties: <debug-symbols>off
        not matched
    next alternative: required properties: <debug-symbols>on <profiling>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 <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:

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 ;

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.

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.