Boost logo

Boost-Build :

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

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

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at