id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
23	Method for expressing complex requirements logic	ghost	somebody	"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.

"	enhancement	new	major	C++ Boost switch (testers)	component1