From: David Abrahams (dave_at_[hidden])
Date: 2004-01-12 12:43:04
Vladimir Prus <ghost_at_[hidden]> writes:
> Zbynek Winkler wrote:
>> > 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.
> There are two questions. First is when to set NDEBUG -- for
> <optimization>speed or for <variant>release.
The latter, IMO. Some people like to keep assertions on even in
-- Dave Abrahams Boost Consulting www.boost-consulting.com
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