We have a project which declares several features that are
used to turn
on and off features in the built library. The targets in the
project are
all dependent on targets from another project (Boost), but
the features
are project-local - they have no effect on boost. Here's a
simple
example of the situation:
A/Jamfile
---------
lib a : a.cpp ;
B/Jamfile
---------
import feature : feature;
feature foo : on off : propagated link-incompatible ;
use-project /A : ../A ;
lib b : b.cpp /A//a ;
C/Jamfile
---------
use-project /B : ../B ;
lib c : c.cpp /B//b ;
A represents Boost, B is our project and C is another
project that
depends on B, for completeness.
When issuing a build request in C:
bjam foo=off
what happens is <foo>off is propagated to all targets,
meaning B is
rebuilt with <foo>off, and then A is rebuilt with
<foo>off. This gives:
A/bin/gcc/debug/foo-off/..
B/bin/gcc/debug/foo-off/..
C/bin/gcc/debug/foo-off/..
The problem here is that <foo> isn't relevant for any
target in A, so
the rebuild is unnecessary. My proposed solution involves
adding another
attribute to feature; "local". So the above
feature-declaration would look:
feature foo : on off : propagated link-incompatible local
;
Local features are associated with the project in which they
are
declared. They are propagated to all build targets, but
removed if the
targets project doesn't match the property project. If they
do match,
the property is propagated back up through
usage-requirements.
When issuing a build request in C, with my changes:
bjam foo=off
we instead get:
A/bin/gcc/debug/..
B/bin/gcc/debug/foo-off/..
C/bin/gcc/debug/foo-off/..
<foo>off is applied to B, and then propagated up to C,
but removed from A.
I have been using the attached path locally with success,
but I may very
well have overlooked some problems or better solutions.
--
Daniel Wallin
Boost Consulting
www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
|
