Changes between Version 19 and Version 20 of AlternativeSelection


Ignore:
Timestamp:
Apr 9, 2007, 7:51:02 PM (19 years ago)
Author:
Dave Abrahams
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • AlternativeSelection

    v19 v20  
    4949in 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 requirements for {{{c}}} contradicts the default for {{{profiling}}}, which is implicitly {{{off}}}.
    5050
    51 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.
     51The 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, there's an easy way to understand this behavior: '''''requirements'' describe how a target must be built, not exactly how it must be requested.''' One point of this proposal is to make the case where there are multiple alternatives more consistent with that principle.
    5252
    5353=== Definition of "Best" ===
    … …  
    170170
    171171This proposal would make several problematic cases into non-problems, would make the handling of multiple alternatives more uniform with the handling of "single alternatives," ''could'' make the syntax/semantics of specifying conditions for alternatives more consistent with that of build requests, and would make some currently-"ambiguous" bjam invocations into well-defined commands. 
    172 Admittedly, it would change the semantics of a common class of configurations when combined with what appears to be an uncommon class of bjam invocations.  So far, we don't have a use case for the current semantics that isn't equally well-covered by this proposal.  However, should we find such a use case, the "optional extension" detailed here would allow us to recover the current semantics (with a different syntax, of course).
     172Admittedly, it would change the semantics of a common class of target declarations when combined with what appears to be an uncommon class of bjam invocations (so uncommon, I claim, that the changes are probably not important to anyone).  So far, we don't have a use case for the current semantics that isn't equally well-covered by this proposal.  However, should we find such a use case, the "optional extension" detailed here would allow us to recover the current semantics (with a different target declaration syntax, of course).
    173173