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.

[dave@…]

I believe the particular case you cite is a hack to use the older version of spirit when compiling with Borland. I'm not sure if there are other such "complex build requirements" but this one ought to be expressed by configuring spirit-1.5.2 in xxx-config.jam and then setting the requirements on the Borland build of serialization to use that version of spirit.

[ghost]

There's also std::locale-support, that can be implemented by appropriate conditional requirements, but that would make many cases that use std::locale-support harder to read.

[ghost]

Implemented approach 1. Will separate 3 into a separate, less important ticket.