Changes between Initial Version and Version 1 of Ticket #23
- Timestamp:
- Jan 28, 2006, 5:05:24 PM (20 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #23 – Description
initial v1 1 1 The 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. 2 2 3 I can see ofthree methods.3 I can see three methods. 4 4 5 5 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: 11 8 {{{ 12 9 build-indirectly spirit : @spirit-builder ; … … 16 13 .... 17 14 } 18 }}} 19 Just like in approach 2, the rule will return extra properties as usage requirements. 15 }}} 20 16 17 18 Approach 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
