QT_NO_DEBUG, Q_ASSERT(), and release build types

[Allen Winter]

Redirecting from k-c-d.  Hopefully, more people here will be interested in discussing this..

On Sunday 11 January 2009 5:34:40 pm Andreas Hartmetz wrote:
> Hi all,
> 
> it occurred to me that QT_NO_DEBUG is not defined in RELWITHDEBINFO build 
> mode. It is defined, since Allen Winter made it so, in RELEASE build mode.
> Note that Debian packages and probably others are built with RELWITHDEBINFO, 
> then the debug symbols are stripped and packaged separately.
> Unfortunately QT_NO_DEBUG has several effects. One of them is to no-op 
> qDebug(), another is to no-op Q_ASSERT(). Its absence also enables things like 
> bounds checking in QList accessors which is obviously detrimental to 
> performance, even though compilers should be able to optimize away the checks 
> in loops.
> Q_ASSERT() is *documented* to be a debugging help, and in my not-so-humble 
> opinion it should be used like that. There are conditions that should never go 
> unnoticed while debugging but nevertheless shouldn't crash for users. Even a 
> memory leak is better than potentially losing data.
> For really unrecoverable errors some to be defined CRASH_ON() or BUG_ON() 
> macro should be used IMO.
> I think that QT_NO_DEBUG should be enabled for RELWITHDEBINFO as well, and if 
> that is not feasible we should look into disabling only asserts and checks; I 
> don't know how to do that though.
> We probably also want to keep kDebug() output enabled even in release 
> builds...
> 
FYI: I created a page on TechBase today that tries to describe all the
various CMAKE_BUILD_TYPE options we have currently.

http://techbase.kde.org/Development/CMake_BuildTypes

Let's try to come to closure on this proposal.
For me, I agree that asserts should be off for release and relwithdebinfo.
But I disagree that kDebug should be on for release.

I am undecided if kDebug+qDebug should be on for relwithdebinfo.
I defer to the packagers on that one.

-Allen