Re: [Boost-build] Target paths idea

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.

- Volodya