How to write such a feature?

View: New views
5 Messages — Rating Filter:   Alert me  

How to write such a feature?

by Sherwood Hu :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.

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?

by Steven Watanabe-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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?

by Sherwood Hu :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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?

by Vladimir Prus :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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?

by Sherwood Hu :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>>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