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-04-01 01:19:06

On Monday 30 March 2009 22:23:14 Alexey Pakhunov wrote:
> (Hit a wrong button. Resending to the mailing list.)
> 
> > 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.
> 
> Are there any non-standard generators that do not use 'flags'? If there are
> it still should be possible to convert all standard generators but keep
> compatibility no filtering mode for others. I think the main problem would
> be the bugs in existing build scripts exposed by changes in the behavior of
> the standard generators.

Yes, we certainly can make some generators filter properties, and make the
default generator do not. More specifically, the compiling generators probably
can do filtering. And the boostbook generators can ignore pretty much everything
except for format (PDF/HTML).

In think the key question is at which level such filtering should be done. The
possible places are 

        - Right at the start of run method
    - Inside 'generated-targets'
    - In constructor of 'action' class

I am not immediately sure which one is best. Given that generator's 'run'
surely can check for specific property, generator should be able to
explicitly say that property XXX is relevant, regardless of other
things.

Note that neither of those approaches will affect property propagation.
That is, if you have metarget A that depends on metatarget B, and
you're building A with 

        toolset=gcc format=pdf

and target a.lib is constructed, then we should be able to detect that
format=pdf has nothing to do with the produced target, and therefore put
it into

   bin/gcc/a.lib

as opposed to

   bin/gcc/format=pdf/a.lib

As the same time, the B metatarget will be still constructed with

        toolset=gcc format=pdf

Ehm, it occurred to me that we need to propagate relevant features back. Say,
A produces a.dll, and B produces b.dll and there's feature mpilib. This
feature might not be relevant to a.dll at all, but relevant to b.dll.
Consequently, this feature is also relevant to a.dll. So, it looks like
some of processing should happen at target level. That is, if we create
virtual-target instance, it should check the properties of all source target,
and avoid discarding properties that are used by them. This in turn suggest
that ultimate filtering should happen a the virtual-target level too.

The above might be too much of a brain dump; please tell what is unclear :-)

> > Also, there should be a mechanism to mark a specific feature as relevant
> or
> > irrelevant for specific generator, or for specific metatarget (*).
> 
> There is a way to call a rule via "<conditional>@my-rule". We can define
> similar "<filter>@my-rule" feature to do the job. BTW can we use
> "<conditional>" to remove properties inherited from a parent?

No. Indirect conditional requirement may only add properties.

> I think starting with "<filter>" syntax is a better idea. It is not as
> intrusive as changing all generators. Once the concept proves itself we will
> be able to apply more radical changes to the generators.

Well, the question with <filter> is whether it applies only to target produced
by the metatarget in question, or is propagated futher. I would say that
making a few generators or target use filtering, such as boostbook and
compilers, might be better.

- Volodya