From: Jurko GospodnetiÄ (jurko.gospodnetic_at_[hidden])
Date: 2008-05-25 14:57:44
> I'm using Boost through the Jamfiles directly (that is "use-project
> boost : [ os.environ BOOST_ROOT ] ;"). When creating some libraries I
> introduce features for its build variants:
> feature usewide : no yes : propagated ;
> lib foo : foo.cpp
> : <usewide>yes:<define>FOO_USE_WIDE
> : <include>.
> Now users of this lib and boost, like:
> exe bar : foo /boost//system ;
> they will force the feature "usewide" on boost as well. Boost will have
> "usewide-no" in its build path, but boost will not be affected by the
> <define> anyhow. Is there a way not to propagate the feature to boost?
> With several libraries the features will make the path be too long and
> additionally boost will be recompiled for each feature, needlessly.
> I could imagine some "realm" for features, marking all targets where the
> feature must affect the build path. And a way to propagate only
> "upwards", meaning from the lib up to the exe, but not from the exe down
> to boost.
> Could that be useful to others?
Yup... I believe that is one of the things missing in Boost Build. A
way to localize features.
Applying a feature to all projects depending on a target from a
project with a feature seems logical. I am not sure though about that
term 'propagated' as that is already used to feature values propagated
to source targets. Although I do not believe this should apply to
project targets, i.e. when referencing a sub-project using a use-project
or build-project rule.
With the following project structure:
Some use cases:
1. Project A declares a feature F, local only to that project.
2. Project B1 declares a feature F, local only to that project.
3. Project C1 declares a feature F, local only to that project.
4. Project B1 declares a feature F, that should affect all targets in
projects B1 & C1.
5. Project C1 declares a feature F, that should affect all targets in
(Not sure if all of them are useful.)
Some question marks that pop up... Imagine the following situation:
* Target A//tA having a source target B1//tB1 which does not depend
on any further targets from project C1.
* Project C1 declares a feature F, local only to that project C1.
* Project B1 contains a target B1//tB2 which depends on a target C1//tC.
Now, when you different targets should they be affected by feature F?
* When you build target A ?
* When you build target B1 ?
* When you build target A//tA ?
* When you build target B1//tB1?
* When you build target B1//tB2?
* When you build target B1//tC?
* When you build all of those targets?
Hopefully I'll find some time by the end of next week to give you
some more feedback.
I have another idea related to properties, that I am hoping to get a
chance to finalize soon - properties specified on targets when they are
specified as sources. An extension of the current property set that can
be stored for built targets (i.e. those that have an action attached to
them) but which would allow this for existing ones as well. Will come in
useful for example for defining installation packages as you can use
this to say: place this source into this package under this path and you
are free to place it under a different path in a different package and
have other targets located in different paths in the same package.
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