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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
