Re: [jamboost] Re: conditional property

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.

- Volodya