Re: [Boost-build] V2/1.34: Can we make it?

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?  

Which one? 

> 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?

23 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 
noise.

26 is:
   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.

- Volodya