From: Zbynek Winkler (zwin_at_[hidden])
Date: 2004-01-12 05:02:32
Vladimir Prus wrote:
> Hi Zbynek,
>>Hello. I was trying to add <define>_DEBUG for <variant>debug and
>><define>NDEBUG for <variant>release. The way I did it was to add to the
>>root Jamfile the following:
>> : requirements
>>Is this the proper way to do this? I just wanted the respected builds to
>>be build with the defines. However I've found out that sometimes both
>>symbols are defined - i.e. when I request debug variant with
>>optimization (example attached). Is this the expected behavior or a bug?
> This is expected behaviour, because builtin.jam contains the following code:
> rule handle-ndebug ( property : properties * )
> return <define>NDEBUG ;
> feature.action <optimization>speed : handle-ndebug ;
> If you ignore the 'feature.action' stuff, all it does is adding <define>NDEBUG
> is <optimization> is set to "speed". The motivation is that I found it rather
> strange when I found that NDEBUG is not set. And <optimization>speed seems
> like a good way to turn on NDEBUG.
> What do you think?
It was a bit unexpected. But when looking into the builtin.jam I've
found the following comment:
# When <optimization>speed is specified, we need to add <define>NDEBUG
# It is done via 'active' features, because it should be done for
# all targets built with <optimization>speed. Since <define> is free, it is
# not propagated, we can't just add it to 'release'. And we cannot make
# <define> propagated, because (i) free features cannot be propagated and
# (ii) this is dangerous.
I agree that it is a good idea to have NDEBUG defined for release
builds. I am just not sure this is the best way. Could we do compose
feature instead? We could then add it the 'release' and 'debug' and make
it propagated (it would expand to <define>NDEBUG for release and
<define>_DEBUG for debug). That way it would be more predictable. It
would identify the variant used for building.
What do you think?
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