Re: [Boost-build] feature, properties, variants, and all the rest

Subject: Re: [Boost-build] feature, properties, variants, and all the rest
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-08-13 21:14:52

On 08/07/2017 11:05 AM, Chambers, Matthew via Boost-build wrote:
> On 8/7/2017 9:42 AM, Stefan Seefeld via Boost-build wrote:
>> On 08/07/2017 10:27 AM, Chambers, Matthew via Boost-build wrote:
>>> On 8/5/2017 9:56 PM, Stefan Seefeld via Boost-build wrote:
>>>>>    The need for propagated features stems from the fact that
>>>>> Boost.Build allows multiple build configurations to be
>>>>> handled simultaneously.  They're basically used for anything
>>>>> that would be global in other build systems, such as the toolset,
>>>>> debug vs. release, static vs. shared, etc.
>>>> Ah, right. Well, right now I don't support multiple build
>>>> configurations. (You can clone artefacts and apply different sets of
>>>> features to them all you want, such as a static and a shared
>>>> version of
>>>> a library. But still, both are represented as two distinct objects,
>>>> and
>>>> I haven't encountered the need to propagate features across the entire
>>>> graph.)
>>> lib a : a.cpp ;
>>>
>>> exe b : b.cpp : <library>a.cpp/<link>shared ;
>>> exe c : c.cpp : <library>a.cpp/<link>static ;
>>>
>>> This very basic example illustrates the need for propagated features.
>>> I don't want to define (clone?) a twice.
>> faber supports that, too, but doesn't require the "propagate" feature
>> attribute for that:
>> https://github.com/stefanseefeld/faber/blob/develop/examples/implicit_rules/fabscript#L21-L23
>>
>> (And I'm not sure that this is in fact an example of "propagate" at all,
>> not even in b2.)
>
> Doh, you're right. I'd need an extra level of indirection for
> propagate to matter.
>
> lib z : z.cpp ;
> lib a : a.cpp z ;
>
> exe b : b.cpp : <library>a.cpp/<link>shared ;
> exe c : c.cpp : <library>a.cpp/<link>static ;
>
> These are the propagated features from builtin.jam:
>
> feature.feature toolset            :                 : implicit
> propagated symmetric ;
> feature.feature stdlib             : native          : propagated
> composite ;
> feature.feature link               : shared static   : propagated ;
> feature.feature runtime-link       : shared static   : propagated ;
> feature.feature runtime-debugging  : on off          : propagated ;
> feature.feature optimization       : off speed space : propagated ;
> feature.feature profiling          : off on          : propagated ;
> feature.feature inlining           : off on full     : propagated ;
> feature.feature threading          : single multi    : propagated ;
> feature.feature rtti               : on off          : propagated ;
> feature.feature exception-handling : on off          : propagated ;
>
> Link/ABI compatibility is another big use case for propagated when
> using things like runtime-debugging and optimization (at least for MSVC).

I'm still not entirely sure I understand "propagate", but it sounds like
what it does is propagation of features "upstream", i.e. from dependent
targets upwards towards prerequisite targets. I.e., if 'B' depends on
'A', and is built with a propagating feature 'p', A is first (re-)built
with p. Right ?

>From the above list, it looks like most of them could actually be global
settings (e.g., toolset, threading, rtti, exception-handling), while for
others I'd actually expect to have full control so I can apply them to
specific targets without propagation (profiling, inlining, optimization).

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...