Re: [Boost-build] Challenge: feature relevance

From: David Abrahams (dave_at_[hidden])
Date: 2006-09-18 09:58:28

Vladimir Prus <ghost_at_[hidden]> writes:

> 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. 

Short answer: yes, this is exactly the feature that addresses your
problem.

> 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

Meaning that all features are considered relevant?

> so that there are no files shared between different variants, and if
> you clean on variant, you don't need to rebuild some other.

IIUC, I don't think that's a good idea.  It seems like a very
specialized use case and I'd rather err on the side of rebuilding.
People can always hack up scripts to do that kind of thing.

> This suggests that we might need an option that controls 
> is relevant features are computed, 
  ^^---"if?"

Try not to think about every possible generalization; you'll never be
able to settle on good design choices for the usual cases unless you
can ignore the unusual ones. :)

> but generally, extra elements in path for 
> HTML, or for midl output, or for bison don't make sense to a user.

Yep.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com