|
Notes |
|
|
(0039531)
|
|
Nils Gladitz
|
|
2015-10-08 06:25
|
|
NDEBUG is defined by the C/C++ standards; _DEBUG is not.
_DEBUG is used in the context of Microsoft (and compatible) compilers where it indicates that a debug runtime is being used.
CMake does set _DEBUG in that context.
For other compilers the _DEBUG macro has no standard defined semantics. |
|
|
|
(0039532)
|
|
Alex Turbov
|
|
2015-10-08 06:28
|
|
No! It shouldn't!
NDEBUG is a "standard" macro which must be defined to eliminate assert() calls.
While _DEBUG (as for me) usually defined by newbies... For example what kind of build you'll get if neither NDEBUG nor _DEBUG are defined? Or both are defined? -- in your code you should handle all that combinations (because user may bring his compile options while build your project)... that makes your code ugly...
just consider that if NDEBUG is not defined -- that is the debug build then! easy! |
|
|
|
(0039533)
|
|
Francis ANDRE
|
|
2015-10-08 08:19
|
|
CMake is supposed to help developpers in porting their software on multiple platforms as various as Windows, Linux, OpenVMS and so on...
As stated by Nils Gladitz "_DEBUG is used in the context of Microsoft (and compatible) compilers where it indicates that a debug runtime is being used". Thus code developped on primarely on Windows using _DEBUG cannot be ported as if using CMake while it is the objective of CMake.
"just consider that if NDEBUG is not defined" is not an option because the library imported is a third party and cannot be modified.
By the way, how do you distinguish between 'debugging available and enabled' and 'debugging available but disabled' and 'debugging not available?
How do you manage release build with assert()? |
|
|
|
(0039534)
|
|
Nils Gladitz
|
|
2015-10-08 09:04
|
|
CMake helps creating portable builds but portability of the source code being build is not within its scope.
Your specific project may rely on _DEBUG being defined but there may also be projects out there which rely on it not being defined.
Users which have written portable source code which does not rely on compiler specific macros like _DEBUG might very much resent CMake for setting it in environments where it is not standard.
Still it is easy enough to define the macro for your own project if that helps with your specific use case without making it a default for everyone else. |
|
|
|
(0039535)
|
|
Francis ANDRE
|
|
2015-10-08 09:47
|
|
OK.. so can you do something to avoid such syntax
set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -D_DEBUG")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -D_DEBUG")
someting like
CMAKE_C_FLAGS_DEBUG += -D_DEBUG |
|
|
|
(0039536)
|
|
Nils Gladitz
|
|
2015-10-08 09:56
|
|
The soon to be released CMake 3.4 adds string(APPEND) but until then no.
If you feel up to it you could give it a try with the current release candidate though. |
|