Re: [Boost-build] Dependencies dropped during concurrent builds

Subject: Re: [Boost-build] Dependencies dropped during concurrent builds
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-11-04 07:58:16

On 03.11.2013 22:32, Steven Watanabe wrote:
> AMDG
>
> Retrying...
>
> On 11/01/2013 10:37 PM, Vladimir Prus wrote:
>> On 02.11.2013 03:13, Steven Watanabe wrote:
>>>
>>> Property handling in Boost.Build is very inefficient.
>>> I've done what I could, but it really needs to be
>>> rewritten completely.
>>
>> Do you have specific design in mind?
>
> No, not really.  The basic problem is that
> we have large lists that are copied around
> with minor variations.  Somehow, we need
> to split it up so that the parts that don't
> change are shared.  It also doesn't help
> that there are multiple representations
> of the same property-set.  (e.g. depending
> on whether composites and subfeatures are
> expanded)

All true. subfeatures in particular seems quite complicated to deal with.

>> Besides optimization, which would
>> certainly needed,
>> it would be nice to change the algorithm for metataget generation so
>> that we first pick toolchain
>> using user-provided properties, and then add other properties inferred
>> from this toolchain,
>> so that for example address-model is always set to some value.
>>
>
> Maybe.  I know people have asked for something
> like this in the past, but I worry that the
> extra complexity would create more surprises
> than it solves.
>
> The algorithm would have to be something like:
>
> rule set-defaults ( requirements * ) ;
>
> rule add-defaults ( properties * )
> {
>      local best-requirements
>      for each set of requirements
>         if properties is consistent with requirements
>             if requirements is a better match than best-requirements
>                 set best-requirements = requirements
>      check if there is no best match or no match at all,
>          and do something appropriate
>      add best-requirements to properties
> }
>
> # example:
> set-defaults <toolset>gcc-4.7 <a>property <more>properties ;
> set-defaults <toolset>gcc-4.8 <another>property ;
>
> add_defaults <toolset>gcc-4.7 ;
>   -> <toolset>gcc-4.7 <a>property <more>properties
> add_defaults <a>property ;
>   -> <toolset>gcc-4.7 <a>property <more>properties

That's about what I had in mind, though maybe the algorithm for selecting default toolset can be
integrated with this one. So that, if I say

        target-os=windows

we pick msvc or mingw gcc, as opposed to having toolset=gcc applied early on.

- Volodya