On Wed, Jul 9, 2014 at 11:43 PM, Thiago Macieira <thiago.macie...@intel.com> wrote: > == 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].
Let me explain why I implemented the journald-logging support the way I did. Some background: on Sailfish, we launch all major system services (and UI) through systemd services (& user session for the UI parts). Those processes may then choose to execute processes of their own (the most prominent example being the UI environment which will launch applications in response to user input). With a default setup, systemd will log everything sent to stderr of systems-launched processes, and child-launched processes will have their stderr output attributed to the systemd service which launched them. I implemented support for this because the situation as described above is frankly unusable for us. Output was wrongly attributed to parent processes, which made tracking down the real source of a problem interesting at times. The other stuff we got (like categorized warnings, a globally usable log - to view whole system effects of things - etc, are just icing on the cake) I wanted to send all non-interactive logging output to systemd. Interactive output (such as running things by hand) should go to the console, on the assumption that there is someone actively monitoring the other end (hence the console check). I added the environment variable workaround after this very problem (QtCreator output) came in in Sailfish. We then adapted our Creator setup to set the environment variable: https://github.com/sailfish-sdk/sailfish-qtcreator/commit/cc880444b433bc3a86305601c1471ffd292c737e https://github.com/sailfish-sdk/sailfish-qtcreator/commit/34c8fcf9d8f749796a7f43fb52997c43f286c480 > == Solutions == > === Heuristically determine at runtime where to send the log === > Which is what I'm trying to do above. > > On Windows, we check whether we have a console and whether stderr is not NUL. > > On Unix, I have implemented the same checks. > > We can also use the fact of whether the main application is in debug mode or > not. I think this is the nicest option, as said above. I may be biased, in that I wrote the initial implementation for journal logging :-) That having been said, as with all heuristics, I think we should strive to make them as simple as possible, otherwise they're going to become non-obvious. My vote would be to just have the correct environment variable injected. It's our knob to customize this behavior already. It's our knob, and we're also responsible for the behavior of it, so why not make use of it? I understand the knee-jerk reaction to modify application \environment, but we're talking about Qt changing Qt's behavior through a public environment variable here, not rocket science, KILL_ALL_HUMANS, LD_PRELOAD, or anything scary . BR, Robin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
