QT_NO_DEBUG, Q_ASSERT(), and release build types

[Andreas Hartmetz]

On Tuesday 13 January 2009 15:37:31 Armin Berres wrote:
> On Tue, 13 Jan 09 00:18, Andreas Hartmetz wrote:
> > On Monday 12 January 2009 00:49:59 Armin Berres wrote:
> > > On Sun, 11 Jan 09 23:34, 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,
> > >
> > > Oh, and FWIW we don't exactly use RELWITHDEBINFO in Debian. In the end
> > > it is RELWITHDEBINFO + -DNDEBUG. IIRC the only reason we don't define
> > > QT_NO_DEBUG is that it would disable the kDebug() output.
> >
> > Hmm, no controversy about the goal. That's certainly fine with me :)
> >
> > Now, does anyone have an idea how to enable QT_NO_DEBUG (or specifically
> > its performance benefits) and still keep debug output enabled? I
> > admittedly did zero research.
>
> I guess it is this part from kdelibs/kdecore/io/kdebug.h:
>
> #if !defined(KDE_NO_DEBUG_OUTPUT)
> # if defined(QT_NO_DEBUG) || defined(QT_NO_DEBUG_OUTPUT) ||
> defined(QT_NO_DEBUG_STREAM) #  define KDE_NO_DEBUG_OUTPUT
> # endif
> #endif
>
> I don't know how well the stuff in kdelibs/kdecore/io/kdebug.cpp works
> if KDE_NO_DEBUG_OUTPUT is not, but QT_NO_DEBUG is defined though...
>
I've looked up the #defines and tested it. Removing the !QT_NO_DEBUG condition 
from kDebug() and setting QT_NO_DEBUG yields the desired result: debug output 
is enabled, asserts (and therefore some internal checks in Qt) are disabled. 
The size of libkdeui with -O1 and debug symbols (my usual build setting) was 
reduced by about 300 kBytes out of ~46 MB, too. I didn't do any performance 
tests; the differencen is probably small.

Any objections to committing this to trunk and/or 4.2?