[Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Koehne Kai]

> -----Original Message-----
> From: development-bounces+kai.koehne=digia.com at qt-project.org
> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
> Behalf Of Thiago Macieira
> Sent: Wednesday, July 09, 2014 11:44 PM
> To: development at qt-project.org
> Subject: [Development] Cake and eating it too for qDebug printing to system
> log - https://codereview.qt-project.org/89357
> 
> == Problematic ==
> Qt 5.3 and dev are currently able to send the output of qDebug, qWarning
> and the rest of the logging framework to somewhere other than stderr.
> That's done on Windows, BlackBerry, Android, and on Linux systems with
> journald.
> Additionally, there's a pending patch for OS X to use the Apple System Log [5]
> and I had a patch for MeeGo that made it go to the standard Unix syslog.
> 
> We have a problem of wanting a cake and eating it too:
> 
> 1) we want applications to send their logging to the system log where
> possible, which usually logs more information like the log level, time,
> application name and PID. Such a system is searchable and may allow us to
> add additional information, like the category (for category logging), file name,
> line number, function context, etc.
> 
> 2) we also want to see the output when we run applications from the
> terminal or capture the output with QProcess.
> 
> The absence of output causes bug reports like [2] and [4].
> 
> == Solutions ==
> === Log to both ===
> Aside from the extra overhead, this causes systems that capture both stderr
> and the system log to record and display the same message twice. That's the
> source of task [3].
> 
> This is not an option.
> 
> === Log to stderr only ===
> That results in loss of information, since the system logs are richer and more
> searchable.
> 
> What's more, on Windows that would result in no output at all for GUI
> applications. I can't find a lot of information on whether GUI applications
> launched from an open command prompt would show anything. IIRC, they
> don't.
> 
> This is not an option.
> 
> === Log to system logs only ===
> This causes reports like [4]. But note that the bug is actually in Creator, for
> failing to read the log store and display the data, like it does on Windows with
> the debug output.
> 
> This is an option.
> 

We might consider also deferring the decision to the application:

=== Defer decision to application ===

Provide a define QT_LOG_TO_CONSOLE  that let QCoreApplication.h record whether it should log to console (QT_LOG_TO_CONSOLE=1), to the system (QT_LOG_TO_CONSOLE=0), or both (QT_LOG_TO_CONSOLE=2). 

Qmake can wrap this into convenience CONFIG arguments:

CONFIG+=log_to_console log_to_system

And individual (system) mkspecs might set a default, so e.g. Windows might get QT_LOG_TO_CONSOLE=2 for gui apps.

If nothing is set, let the heuristic kick in ...

Regards

Kai