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 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. This is similar to how stlport module works at the moment.
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 )
   {
      ....
   }
   

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.