> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Thiago Macieira > Sent: Wednesday, July 09, 2014 11:44 PM > To: [email protected] > 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
