Re: [Boost-build] How to stop propagating properties to dependents.

Subject: Re: [Boost-build] How to stop propagating properties to dependents.
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-03-30 13:10:20

On Monday 30 March 2009 20:47:29 Alexey Pakhunov wrote:
> Hi,
> 
> This topic has been brought up a couple of time already. See
> http://lists.boost.org/boost-build/2009/02/21272.php for instance.
> 
> Say I have a dependency chain: A -> B -> C -> D. I.e. target A depends on B
> and so on. Currently whatever (propagated) requirements target A has they
> will be propagated down to B, C and D even if the generators B -> C and C ->
> D are not using them. This can lead to multiple variants of D to be built
> even if it it not necessary. Consider the following example:
> 
> make header : source : @generate_header ;
> 
> actions generate_header
> {
>     echo foobar > $(<)
> }
> 
> lib foo : foo.c : <implicit-dependency>header ;
> lib bar : bar.c : <implicit-dependency>header <exception-handling>off ;
> exe rabbit : foo bar rabbit.c ;
> 
> In this "make header" will be run twice: once for a property set with
> <exception-handling>off and once for a property set without it. It is not
> needed because the result produced by "make header" does not depend on the
> value of <exception-handling> feature.
> 
> 
> It seems this can be solved relatively easily. If generators could filter
> passed property sets and remove anything they are not interested. This way
> "make header" could remove all properties it does not use and generate a
> single copy of the header. The method "generator::run" seems to be the only
> place where a property set is passed so the filtering can happen there.
> 
> Do you think it is a right direction to move to solve this issue?

The primary question is how those relevant properties can be determined. For standard
generators such as compilers it would be reasonable to look at all 'flags'
settings for the corresponding rules and see which properties are in use there.
Also, there should be a mechanism to mark a specific feature as relevant or
irrelevant for specific generator, or for specific metatarget (*).

- Volodya

(*) Metatarget is the shiny new terminology to mean "main target"
definably in Jamfile.