From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-01-12 05:22:50
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. Second is how to set them: via
"active" features or composite features.
The answer to the last question is simple -- "active" features are used in
only one place, and I'd be happy to remove them completely.
The answer to the first question is not that simple. Assume you've created a
new variable 'super-optimized-release'. If it's inherited from 'release',
with current code you'll get NDEBUG automatically. If NDEBUG is set for
<variant>release, you'll suddenly get no NDEBUG, and your
super-optimized-release will suddenly become pretty slow.
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