Changes between Version 11 and Version 12 of AlternativeSelection


Ignore:
Timestamp:
Mar 26, 2007, 6:31:38 AM (19 years ago)
Author:
Dave Abrahams
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • AlternativeSelection

    v11 v12  
    8181
    8282  '''Definition:''' a top-level target's explicitly-requested build properties are those that
    83   are specified on the command line, e.g. {{{bjam '''threading=multi'''}}}.  A dependency
     83  are specified on the command line, e.g.
     84    {{bjam }}} '''{{{threading=multi}}}'''. 
     85  A dependency
    8486  target's explicitly-requested build properties are those that are propagated from its dependent
    8587  target(s).  As a special case, {{{<toolset>}}} is always considered to be explicitly requested,
    … …  
    9294== Not A Pure Extension ==
    9395
     96This is almost a pure extension (i.e. one that does not change the semantics of any currently-working cases) but not quite.  One case that it would change is as follows ('''Example 3'''):
     97
     98{{{
     99lib a : a.cpp ;                                           # 1st alternative
     100lib a : a-dbg.cpp : <threading>multi <debug-symbols>on ;  # 2nd alternative
     101}}}
     102
     103Today,
     104
     105{{{
     106bjam debug-symbols=on
     107}}}
     108
     109will select the first alternative.  Under my proposal, it would select the 2nd.  That leaves these questions:
     110
     111 #. Is that an important difference?  That is for you to answer.
     112 #. How would we get the current semantics?  Read on...
    94113
    95114== Optional Extension to this Proposal ==
    96115
     116Currently, selecting a target alternative (when it's not the only alternative) requires that ''all'' its requirements be matched.  It's not yet clear that the "require all requirements" is actually useful in real-world scenarios (I admit that not requiring requirements is a bit weird, but remember that we already don't require them for the single-alternative case, so maybe "requirements" is a misnomer anyway).  If we decide it is important to support alternatives where all requirements are actually required in order to be selected, we would need a new notation.  I suggest:
     117
     118{{{
     119lib a : a.cpp ;                                           # 1st alternative
     120lib a : a-dbg.cpp : <threading>multi/<debug-symbols>on ;  # 2nd alternative
     121}}}
     122
     123In this case, the 2nd alternative would only be selected if ''both'' {{{<threading>multi}}} and {{{<debug-symbols>on}}} were in the explicitly-requested properties.
     124The exact way the matching algorithm should be changed to handle this capability, and especially what it would do with multiple slash-separated elements in the requirements, is a topic for discussion and research.  We may decide it isn't important to handle this case, so it's not worth investing in a solution at this point.
     125