Method for expressing complex requirements logic

[ghost]

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.

I can see of three methods.

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.

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.

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:

   build-indirectly spirit : @spirit-builder ;
   # The parameters of the run as the same as for generator.run
   rule spirit-builder ( name project ? : sources * : property-set )
   {
      ....
   }
   

Just like in approach 2, the rule will return extra properties as usage requirements.