[Kde-pim] Review Request 121096: fix compilation failure when -DQT_NO_DEBUG_OUTPUT
René J.V. Bertin
rjvbertin at gmail.com
Tue Nov 11 15:48:47 GMT 2014
> On Nov. 10, 2014, 5:08 p.m., Laurent Montel wrote:
> > As you wrote it's just a workaround.
> > You need to find why you have this error.
> > For example post the error.
> > We can't just add this workaround.
> >
> > Regards
>
> René J.V. Bertin wrote:
> I have this error because I compile with -DQT_NO_DEBUG_OUTPUT . Given the complexity of the kind of object one can << into qDebug() I'm not even going to try to understand what function of what class messes up; that's up to a regular kdepim or kdepimlibs developer who knows his or her way around the code. All I could do is replace credentialsData with a void stub function when QT_NO_DEBUG_OUTPUT is defined, and that's not any more or less a workaround.
>
> In fact, someone of you ought to try a build with this flag defined, because a comparable error also popped up at resources/imap/subscriptiondialog.cpp:376
>
> Laurent Montel wrote:
> I think that it's not supported.
> Indeed kdepim-runtime reports a lot of compile error with it.
> We will not add a #ifdef... in each kDebug()<< KDateTime/QVAriant etc in code
> Nobody tried it previously. So not necessary to lose time against it.
> kdelibs compiles with this flag ?
>
> René J.V. Bertin wrote:
> At least akonadi builds with this flag; for kdelibs I've never tried. Isn't required either because it adheres to the guideline of not outputting loads and loads of messages when debug output is switched off through kdebugdialog.
> That is NOT the case with kdepim-runtime (and akonadi), as came up on the kdepim-user ML very recently.
>
> As far as I'm concerned I made this RR mostly to bring the issue to attention. If not adhering to guidelines, log pollution, waste of CPU cycles and storing potentially sensitive information in places like ~/.Xsession-errors are of no concern to you ... well, I can simply offer my patches to Ubuntu and MacPorts for downstream application.
>
> Laurent Montel wrote:
> kdelibs uses kDebug()<< as kdepim-runtime, so if it doesn't polute .xsession kdepim-runtime will not polute too :)
> When we compile in release mode:
> "#ifdef QT_NO_DEBUG /* The application is compiled in release mode */
> # define KDE_DEBUG_ENABLED_BY_DEFAULT false
> #else
> # define KDE_DEBUG_ENABLED_BY_DEFAULT true
> #endif
> "
> so it's not necessary to patch all code it's disable by default so it will not polute .xsession-errors
> Regards.
>
> René J.V. Bertin wrote:
> Please check the thread "chatty akonadi apps" in the kdepim-user mailing list archives; that's an ongoing thread with enough examples.
> I wouldn't have started a witch hunt if I didn't get WAY too much output on my terminal after typing `akonadictl restart`. Part of it comes directly from akonadiserver (dixit Daniel), but the rest comes from akonad resources from kdepim-runtime that use qDebug instead of kDebug.
>
> There are 38 calls to qDebug in kdepim-runtime (some of which are commented out), and 21 calls to qWarning. KDE4 guidelines say that those should use kDebug and kWarning.
>
> Of course I can convert this RR into one that patches the code to do those conversions ... that's in any case what I'm going to do check out instead of building with QT_NO_DEBUG_OUTPUT
>
> Laurent Montel wrote:
> Yes perhaps there is some qWarning/qDebug but your patch is against a kDebug...
>
> René J.V. Bertin wrote:
> That's why I said that I was going to check out the effect of converting qDebug and qWarning into their 'k' equivalents and build without Q_NO_DEBUG_OUTPUT.
>
> It was Daniel who suggested building with that flag, I presume he didn't realise how many errors that would raise (in fact, not THAT many; the impression is skewed by the amount of candidates the compiler prints out for each error).
>
> Daniel Vrátil wrote:
> My suggestions was purely for Akonadi, not for kdepim{,libs,runtime} - those can be from 99% controlled from kdebugdialog. The only applications that cannot be controlled via kdebugdialog is Akonadi Server, so that's where I suggested disabling debug output (or building in release mode, which should be equivalent).
Daniel: so those 50-some calls I cited above are 1% of the total debugging output statements? :)
As I said in PM, deactivating debug output in akonadi and converting all qDebug and qWarning calls to kDebug/kWarning in kdepim-runtime seems to give a considerable speed-up in KMail, esp. for large folders.
I wonder to what extent deactivating debug output through kdebugdialog also prevents wasting the CPU cycles used up by creating pretty print text from complex objects?
- René J.V.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121096/#review70198
-----------------------------------------------------------
On Nov. 10, 2014, 5:03 p.m., René J.V. Bertin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121096/
> -----------------------------------------------------------
>
> (Updated Nov. 10, 2014, 5:03 p.m.)
>
>
> Review request for KDEPIM.
>
>
> Repository: kdepim-runtime
>
>
> Description
> -------
>
> resources/dav/resource/settings.cpp has an issue in Settings::accountsUsername that causes compilation to fail when -DQT_NO_DEBUG_OUTPUT. The real issue may in fact lie in the definition GetCredentialsJob::credentialsData; the patch provided here implements a workaround.
>
>
> Diffs
> -----
>
> resources/dav/resource/settings.cpp 1d32418
>
> Diff: https://git.reviewboard.kde.org/r/121096/diff/
>
>
> Testing
> -------
>
> Ubuntu 14.04 with kdelibs 4.14.2 .
>
>
> Thanks,
>
> René J.V. Bertin
>
>
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
More information about the kde-pim
mailing list