QT_NO_DEBUG, Q_ASSERT(), and release build types

[Andreas Hartmetz]

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...

Cheers,
Andreas