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

[Alejandro Exojo]

El Friday 11 July 2014, Thiago Macieira escribió:
> On Friday 11 July 2014 00:17:48 Alejandro Exojo wrote:
> > 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).
> 
> You can still install your handler to do that. We're talking about the
> default and I'd like to have a consistent behaviour across different OS.
> It makes my implementation simpler.

Yes, but as you noted in the changelog/commit message, this is a behaviour 
change, and this way the default message handler could be a little less 
useful. Since qInstallMessageHandler returns the pointer to the default 
message handler, one could wrap it to "decorate" it.

We did that to check if we wanted stderr or not, and then call the default 
message handler of 5.2 or not. Then we did our journal logging. In 5.2 that 
always printed to stderr with the nice formatting of QT_MESSAGE_PATTERN, etc. 
which is very convenient.

If the heuristic is good enough for all the use cases (seems at a first glance, 
but I want to be 100% sure, and I don't see the one on debug build), no 
problem. But otherwise, the only way to force the default message handler to 
do its thing on stderr is the environment variable, which is kind of odd, 
since we might want to set it in the application code to notify the library 
code of what we want.

> > 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.
> 
> There you go. That's the default on OS X and will probably become the
> default on Linux if the desktops switch to user-mode systemd.

Yep, now I see it. You're right is OK as a default.
 
> > 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.
> 
> I agree. Which is why my proposal email does not talk about debug mode.

Oh, I'm confused then. It does in the Patch Set 6, no?

> > 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.
> 
> If we did it like that and if you ran debug-mode applications in your
> system. That's not a common situation. And besides, systemd will capture
> stderr anyway, just will less information.

But why would that be uncommon? If you have an app that crashes on a certain 
environment, you might want to have both the better system logging and the 
debug symbols, isn't it?

I know the matrix of use cases is large, and is not possible to please 
everyone with the defaults, but the check for a debug build really confuses 
me. :)

So, would you see as good another patch that hints/bypasses the checks through 
an application attribute? Or the environment variable?

Sorry if I'm being a bit picky. After more thought, yes, I think the defaults 
are sound. But I would be a bit more confident if there is some "knob" I can 
touch, as Robin said. But I'm so much more a Qt user than a developer, so we 
all want those knobs to play with. :-)

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net