From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-01-31 11:09:40
On Tuesday 31 January 2006 19:02, David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> > On Monday 30 January 2006 22:44, David Abrahams wrote:
> >> If there is any hope of replacing v1 with v2 for the upcoming release,
> >> I'd like to know what needs to be done and how I can help.
> > Help with either
> > https://zigzag.cs.msu.su:7813/boost.build/ticket/23
> > or
> > https://zigzag.cs.msu.su:7813/boost.build/ticket/26
> Can we move this to another server?
> As usual, the server is
> unreachable and/or the response time is long. I've been waiting 60
> seconds for the first link to come up and still nothing.
Can you run the "traceroute" command to verify where the bottleneck is?
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.
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.
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.
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
Sometimes it's desirable to skip building of a specific target, because
building is known to fail, for example:
compile a : <toolset>borland:<build>no ;
Need to implement this <build>no that's present in V1.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk