On Monday 12 January 2009 00:15:26 Ingo Klöcker wrote: > On Sunday 11 January 2009, 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... > > I don't think keeping kDebug() enabled in release builds is a good idea > because of highly likely performance problems. At least, not if logging > kDebug() messages is turned on by default. If logging of debug messages > was enabled but turned off by default and could easily be turned on by > the user if necessary (e.g. through kdebugdialog) then I would agree > that enabling it even in release builds would probably be a good idea. > Committed like that, revision 916186. You can see the whole diff here: http://mercurial.intuxication.org/hg/kdelibs/rev/287994f46c5d
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
