[CMake] Tests with assert and Release build type

Magnus Therning magnus at therning.org
Thu Dec 24 07:48:59 EST 2015


Ruslan Baratov writes:

> On 22-Dec-15 04:07, Magnus Therning wrote:
>> Ruslan Baratov writes:
>>
>>> On 20-Dec-15 01:31, Magnus Therning wrote:
>>>> Ruslan Baratov writes:
>>>>
>>>>> How about using RelWithDebInfo? See:
>>>>> http://stackoverflow.com/a/28124715/2288008
>>>> Hmm, I'm probably missing something but how does that solve the issue
>>>> with some targets requiring NDEBUG to be *undefined* and other targets
>>>> requiring NDEBUG to be defined?
>>> I don't think that building targets with different NDEBUG values is a
>>> good idea. More correct approach will be to introduce custom macro to
>>> allow checks (i.e. FOO_NDEBUG/FOO_DEBUG).
>> Why not?
> It is possible to hit situation when ODR will be violated, e.g. if
> somebody define optional member in structure with "#if defined(NDEBUG)"
> condition. Something like this:
> http://stackoverflow.com/questions/20833226/library-headers-and-define

Yes, if we ever start using the NDEBUG macro to control anything in our
code then I'll have to worry about this, as it stands right now it's
only the `assert` from `assert.h` that cares about it.

If I'm reading you correctly you are advocating I simply get rid of the
use of those asserts altogether instead.

/M

--
Magnus Therning              OpenPGP: 0x927912051716CE39
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus

The results point out the fragility of programmer expertise: advanced
programmers have strong expectations about what programs should look like,
and when those expectations are violated--in seemingly innocuous
ways--their performance drops drastically.
     -- Elliot Soloway and Kate Ehrlich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151224/5f094731/attachment.sig>


More information about the CMake mailing list