G_log_structred and "CODE_XXXX" key vaule pairs

I’m trying to move to using structured logging, but I seem to missing something…
The documentation mentions using keys like “CODE_FILE” and “CODE_FUNC”, and I can see where these key/values get added in the G_DEGUB_HERE macro for example. But niether the keys or values t seem to make it into any logging output. In fact I can’t see anywhere in the sources where these keys are recognized. Do I have to produce my own GLogWriterOutput function to get these values into my logging output ? If so can the documentation be updated to mention this and not suggest using keys that are not implemented by the default settings.

There already is g_log_writer_journald. Here is my test case:

#include <glib.h>

int main() {
    g_log_set_writer_func(g_log_writer_journald, NULL, NULL);
    return 0;

With the above code I get the following:

$ gcc -o test-log test-log.c $(pkg-config --cflags --libs glib-2.0)
$ ./test-log
$ journalctl -o verbose -n 1

Thanks for the reply.

Sorry, but I don’t want to use anything that uses systemd features and mixes my applications logging with anything else. It needs to log to a file with just my applications output in it.

Then you need to write your own GLogWriterFunc.

The default output function (g_log_writer_default()) writes all keys to systemd (if available), which is why you don’t see any code which handles CODE_FILE/CODE_FUNC/etc. explicitly. They are not printed to stdout by g_log_writer_standard_streams() because that would be too verbose.

Ok, I’ll have a go at my own GLogWriterFunc but looking at the sources for the default ones they seem to use a lot of support functions that are internal and are not be available outside the library.
This looks like it makes the job harder than it should be.

But the decision “They are not printed to stdout by g_log_writer_standard_streams() because that would be too verbose.” seems rather arbitrary and confusing when that behaviour isn’t described in the documentation.

At some point we have to stop writing things in the documentation, or the documentation might as well be a copy of the code.

That is as may be, but when the documentation fails to explain why using something it mentions doesn’t work I think you’ve stopped too soon ! If the documentation was appropriate I would not have had to resort to the source code to work out why it doesn’t work. “Use the Source” is not an excuse for poor documentation ! By the way I generally find the GTK documentation to be very good.

If you’ve got concrete suggestions for how to improve the documentation (i.e. in a diff format) please create a merge request or issue against GLib and we can discuss the merits of those particular suggestions. :slight_smile: Thanks!

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.