Changes between Initial Version and Version 1 of Ticket #23


Ignore:
Timestamp:
Jan 28, 2006, 5:05:24 PM (20 years ago)
Author:
ghost
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #23 – Description

    initial v1  
    11The tests for Boost Serilization library have quite a complex logic for requirements. For example, {{{toolset:require-boost-spirit-support}}} does will check if the current toolset is borland, and if so check that global var {{{SPRIT_ROOT}}} is defined, and if it's defined, add {{{<include>$(SPIRIT_ROOT)}}} to requirements. V2 does not have a comparable mechanism.
    22
    3 I can see of three methods.
     3I can see three methods.
    44
    55 1. Allow rule names in the requirements list, just like in V1. The rule will be called with the current list of properties and will return the new list. In a sense, this will be equivalent to conditional requirements.
    6 
    7  2. Write a completely special target with a custom generator. The custom generator's 'run' method will contain the same logic and return new properties as
    8 usage requirements.
    9 
    10  3. Allow to customize build process of a target without creating complete custom generator, but just creating a rule that will act as 'run' method of the generator. For example:
     6 2. Write a completely special target with a custom generator. The custom generator's 'run' method will contain the same logic and return new properties as usage requirements. This is similar to how {{{stlport}}} module works at the moment.
     7 3. Allow to customize build process of a target without creating complete custom generator, but just creating a rule that will act as 'run' method of the generator. For example:
    118{{{
    129build-indirectly spirit : @spirit-builder ;
     
    1613   ....
    1714}
    18 }}}
    19 Just like in approach 2, the rule will return extra properties as usage requirements.
     15}}}
    2016
     17
     18Approach 3 can have wider utility -- it's often desirable to control build process details, but writing a custom generator each time is too much syntax noise.
     19