Re: [Boost-build] Challenge: feature relevance

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-09-18 04:28:17

On Monday 18 September 2006 12:08, Andrei Melnikov wrote:
> On 18/09/06, Vladimir Prus <ghost_at_[hidden]> wrote:
> > Hi,
> > one of the issues that would be very nice to fix for the next release
> > is "feature relevance":
> >
> >      https://zigzag.cs.msu.su:7813/boost.build/ticket/4
> >
> > In short, we should not be generating BoostBook documentation into
> > 'gcc/debug' directory, since HTML files will be the same, no matter what
> > compiler is used to generate executables.
> >
> > This issue involves computing for each action which features affect it by
> > looking at all 'flags' rule invocation, and then removing irrelevant
> > features from properties of targets.
>
> Is this related to midl-toolset issues we discussed some time before?
> C toolsets and BoostBook toolsets are not the only independent
> toolsets. For example, IDL -> TLB generation isn't affected by
> <runtime-debugging>, threading or <link> features, so the same type
> library can be linked for all compilers and variants. But it can be
> affected by <define> and other C preprocessor features.

This is yet another example where 'relevant features' would help. Yet another 
example is 'bison' -- that just generates a header file and does not depend 
on any features.

When we discussed this before, Juergen mentioned that it can be nicer to use 
full set of properties for all paths, so that there are no files shared 
between different variants, and if you clean on variant, you don't need to 
rebuild some other. This suggests that we might need an option that controls 
is relevant features are computed, but generally, extra elements in path for 
HTML, or for midl output, or for bison don't make sense to a user.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2