Method for expressing complex requirements logic

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Method for expressing complex requirements logic

Vladimir Prus

Hi!
Some of the Boost libraries have pretty contrived logic in their regression
tests. So example, if the toolset is borland, the serialization library will
check for global variable SPIRIT_ROOT, and if that's set, add its value to
<include>, and if it's not set, error out.

In V1 this is accomplished by adding a name of a rule to requirements, which
rule will be called to compute extra requirements.

The question is how to best implement this in V2. I've outlined three posible
methods in

   https://zigzag.cs.msu.su:7813/boost.build/ticket/23

Anybody can comment which one seems best?

- Volodya

_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build
Reply | Threaded
Open this post in threaded view
|

Re: Method for expressing complex requirements logic

Phillip Seaver
Vladimir Prus wrote:
> Hi!
> Some of the Boost libraries have pretty contrived logic in their regression
> tests. So example, if the toolset is borland, the serialization library will
> check for global variable SPIRIT_ROOT, and if that's set, add its value to
> <include>, and if it's not set, error out.
>
> In V1 this is accomplished by adding a name of a rule to requirements, which
> rule will be called to compute extra requirements.
#1 (allow rule names in requirements list) sounds the easiest from a
user perspective at first glance.

For #3 (custom replacement for generator.run), it depends on what would
have to go inside the rule.  If I wanted to do a custom executable
build, would I need to copy linking-generator.run, or would we just call
it after making whatever changes to the parameters we needed?

If it's just a case of calling the run rule for the generator that
should have been called, they look about the same, except that you can
modify the sources with #3.  If you don't need to do that, #1 sounds
better, because then you still have the target name to tell you at a
glance what it's going to build ("lib", "exe", etc.) instead of having
to read through the rule's code.

Phillip

_______________________________________________
Boost-build mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-build