|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
|
|
How to write such a feature?The <define> property in Boost.Build does not propagate.
This causes problems in my project, as the unit tests require a macro UNIT_TEST
to be defined and the main library is built with this macro defined. Because
<define> does not propagate, I have to specify <define>UNIT_TEST at
the command line. If the library is built first without this macro, the unit
tests will not be built successfully. I am considering to add a <unit-test> feature and make
<define>UNIT_TEST propagate. Import feature : feature ; Feature unit-test : on off : propagated ; But how to add <define>UNIT_TEST when
<unit-test>on? Thanks. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build |
|
|
Re: How to write such a feature?AMDG
Sherwood Hu wrote: > The <define> property in Boost.Build does not propagate. This causes > problems in my project, as the unit tests require a macro UNIT_TEST to > be defined and the main library is built with this macro defined. > Because <define> does not propagate, I have to specify <define>UNIT_TEST > at the command line. If the library is built first without this macro, > the unit tests will not be built successfully. > > I am considering to add a <unit-test> feature and make <define>UNIT_TEST > propagate. > > Import feature : feature ; > > Feature unit-test : on off : propagated ; > > But how to add <define>UNIT_TEST when <unit-test>on? > Use a composite feature. They are documented at the bottom of http://www.boost.org/boost-build2/doc/html/bbv2/extending/features.html In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build |
|
|
Re: How to write such a feature?Steven,
Thanks. I followed the instruction and they worked. feature enable-unit-test : on off : composite propagated ; feature.set-default enable-unit-test : off ; feature.compose <enable-unit-test>on : <define>_UNIT_TEST ; feature enable-debug-module : on off : composite propagated ; feature.set-default enable-debug-module : off ; feature.compose <enable-debug-module>on : <define>BK_DEBUG_MODULE ; Now I have another question. The attribute "propagated" is quite strong and applies on the whole dependency tree. Is there an attribute that only applies to one target but stronger than what the "free" attribute can provide? Assume that my unit test exe is linked to libA, which has dependency libB. I want the new feature <enable-debug-module> only applies to libA not libB. That is, the test exe is linked to libA built with <enable-debug-module>on and libB built with <enable-debug-module>off. Is this possible? -----Original Message----- From: boost-build-bounces@... [mailto:boost-build-bounces@...] On Behalf Of Steven Watanabe Sent: Tuesday, September 22, 2009 12:17 AM To: Boost.Build developer's and user's list Subject: Re: [Boost-build] How to write such a feature? AMDG Sherwood Hu wrote: > The <define> property in Boost.Build does not propagate. This causes > problems in my project, as the unit tests require a macro UNIT_TEST to > be defined and the main library is built with this macro defined. > Because <define> does not propagate, I have to specify <define>UNIT_TEST > at the command line. If the library is built first without this macro, > the unit tests will not be built successfully. > > I am considering to add a <unit-test> feature and make <define>UNIT_TEST > propagate. > > Import feature : feature ; > > Feature unit-test : on off : propagated ; > > But how to add <define>UNIT_TEST when <unit-test>on? > Use a composite feature. They are documented at the bottom of http://www.boost.org/boost-build2/doc/html/bbv2/extending/features.html In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build |
|
|
Re: How to write such a feature?On Tuesday 22 September 2009 Sherwood Hu wrote:
> Steven, > > Thanks. I followed the instruction and they worked. > > feature enable-unit-test : on off : composite propagated ; > feature.set-default enable-unit-test : off ; > feature.compose <enable-unit-test>on : <define>_UNIT_TEST ; > > feature enable-debug-module : on off : composite propagated ; > feature.set-default enable-debug-module : off ; > feature.compose <enable-debug-module>on : <define>BK_DEBUG_MODULE ; > > Now I have another question. The attribute "propagated" is quite strong > and applies on the whole dependency tree. Is there an attribute that > only applies to one target but stronger than what the "free" attribute > can provide? > > Assume that my unit test exe is linked to libA, which has dependency > libB. I want the new feature <enable-debug-module> only applies to libA > not libB. That is, the test exe is linked to libA built with > <enable-debug-module>on and libB built with <enable-debug-module>off. > > Is this possible? This is not presently possible. Is propagation to libB causing you any troubles? - Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build |
|
|
Re: How to write such a feature?>>This is not presently possible. Is propagation to libB causing you any
troubles? >>- Volodya Vlad, Thanks for the answer! Unfortunately it has side effect when this feature propagates. In this case, libA has a dependency - libB. The unit test exes are written for testing libA thoroughly, not for libB (as it is covered by its own tests). The feature <enable-debug-module> adds debug tracing for the module enabled. We'll end up with getting unnecessary traces from libB. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build |
| Free embeddable forum powered by Nabble | Forum Help |