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.
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
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