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
> 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,
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.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk