El Wednesday 09 July 2014, Thiago Macieira escribió: > === 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.
Why not? Task [3] is an issue in Qt Creator, isn't it? Why it needs to read the system log on Windows? Logging to the console _and_ journald has proven very useful to us. We did it specifically for an application using Qt's API, and developers can code, press Run (in Creator), and see the output in the same window with all the QT_MESSAGE_PATTERN goodness. Afterwards, if it's too noisy, or if you disabled some category, you can check the logs on journald (we logged all categories, even the disabled ones, to the journal, since we had or own message handler). It's not hard at all to do it on your application if you want to fine tune it. Actually, I never expected to see the journald logging in Qt, but having it IMHO it's a boon, since you can use the feature for 3rd party applications. Only downside is that you might need to collect what your application outputs to stderr from a non-Qt library. Then yes, you might get duplicated messages. > === Heuristically determine at runtime where to send the log === > 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 see this as two orthogonal things. Why would one prefer the console on a debug build? You might need to put the program in debug mode on the target hardware (only device where you have the peripherals), and need the enriched system logging and the debug symbols. This is the most inconvenient change, since you might need to change the systemd unit file to set the QT_LOGGING_TO_CONSOLE environment variable to have the built in journald logging. > == Summary of systems == > System services on Linux with journald: > - default stderr: captured into system log > - system logging: available > - is stderr useful: yes, for launching from terminal Note that you can teach systemd to ignore stderr/stdout if wanted. If the app is written with Qt, that can be a sane default. > And then some desktop Linux distributions decided to enable journald. The > effect of that is task [6]: Qt Creator shows no output because it goes to > journald. But this comment is/was in the code: "We use isatty to catch the obvious case of someone running something interactively. We also support environment variables for Qt Creator use (...)" I thought that it was agreed/known to Qt Creator developers that QT_LOGGING_TO_CONSOLE might be gently defaulted to true for applications run by Creator. That environment variable seems like "API" to me, and a useful one that Creator could use. Of course they couldn't predict some distributions would pass -journald to configure. >From the other messages: > * Support for journald in the pre-built Qt binaries: > Disabled. Probably will be that way for a long time. If Qt binaries are built with and old Ubuntu, they just don't have libsystemd-journal. > Note: if journald is writing to volatile storage, regular users can't read > the log. Therefore, system logging is not available. > > Linux distributions should not enable journald logging unless regular users > can read the output. I think users can read their user journal, independently of the storage. This is as user nobody: $ systemd-journalctl Showing user generated messages only. Users in the group 'adm' can see all messages. Pass -q to turn this message off. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development