From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-12-03 05:35:30
Jurko GospodnetiÄ wrote:
> u Hi.
>> Or you could just not represent the feature when it has its default
>> value, just as feature relevance worked in BBv1.
> That is the way BBv2 already works and that is not what I meant.
> I meant allowing a project to explicitly specify that it will use
> only one value for a given feature and so no matter how the feature is
> defined (whether it has a default value or not, whether its build folder
> is created when its default value is used, whether the specified value
> is the feature's default value or not...) the build system will not
> create a folder for that feature or allow the project to be built using
> a different feature value.
> Here's an example:
> 'runtime-link' feature has 'dynamic' set as its default value and I
> do believe the 'runtime-link-dynamic' folder is never created. However
> we have projects (many in fact) that use static 'runtime-link' feature
> value, and they must never use dynamically linked runtime libraries. For
> those projects, the build folder 'runtime-link-static' created by Boost
> Build is redundant and could be skipped.
> My suggestion would allow such projects to specify such 'fixed'
> feature values which would allow them to:
> 1. Not create such unnecessary build folders, thus reducing the
> build folder path length and making the folder path easier to read when
> in the context of that project.
> 2. Create subprojects that can only be built with one feature value
> and have them ignored/not-built if the main project is built with a
> different feature value (useful e.g. if you have client/admin build
> types for the master project and some sub-projects are products that
> make sense only in admin mode builds and you do not want their client
> mode builds to be even attempted).
It's worth to generalize this, and allow a project to specify custom
function used to compute target paths. The question, then, is what
do to if the rule is changed by the user in a way that path XXX
is possible with previous version of the rule and with new version of
the rule, but with different properties.
Maybe I should actually implement MD5 build signatures.
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