Make decision on whether to show code location in journal messages based
on whether the WpLogTopic would enable DEBUG level messages.
Add wp_logt_checked API to take WpLogTopic as input to make this
possible, and deprecate wp_log_checked.
Define WP_USE_LOCAL_LOG_TOPIC_IN_G_LOG in project scope, so that we always
use this feature in our codebase without causing problems for other projects.
Fixes#571
Change design of WpLogTopic so that it allows for changing their log
levels at runtime.
Add wp_log_topic_register/unregister functions to track lifetime of the
topics.
Auto-register statically defined log topics.
Make the topic registration threadsafe, in case it is done from
constructors that run in a different thread than main thread.
Syslog calls this level "notice" and I prefer it because we use it
to display significant messages that are not warnings, but they
are not really "standard", as GLib wants them to be. There is nothing
"standard" about log messages in general.
Also, make these notice messages be enabled at debug level 2, together
with warnings. The default log.level is 2 and it is a good idea to show
notices by default too.
Finally, show them in the log with "N" and also change criticals to be
shown with "E", meaning "error"... Then promote G_LOG_LEVEL_ERROR
messages to be shown with "F", meaning "fatal", because in fact these
messages are always fatal and always call abort(). Still, keep the term
"critical" in the functions to make sure that whoever uses them is aware
that this level is only for critical conditions and not suitable to
display any kind of error.
* initialize all log-related features in a new wp_log_init() function
* remove the ability to change the log patterns later, as the log
topics are not referenced by the log system and there is no way to
re-initialize them with different levels (we can still implement this
in the future, if necessary, though)
* introduce the notion of a "global log level", referenced by all topics,
and make the topics know if they have a custom level or not, like in
pipewire; this is necessary to be able to set the level in the config
file, which is read later by pw_context / WpCore.
The intention is to make checks for enabled log topics faster.
Every topic has its own structure that is statically defined in the file
where the logs are printed from. The structure is initialized transparently
when it is first used and it contains all the log level flags for the levels
that this topic should print messages. It is then checked on the wp_log()
macro before printing the message.
Topics from SPA/PipeWire are also handled natively, so messages are printed
directly without checking if the topic is enabled, since the PipeWire and SPA
macros do the checking themselves.
Messages coming from GLib are checked inside the handler.
An internal WpLogFields object is used to manage the state of each log
message, populating all the fields appropriately from the place they
are coming from (wp_log, spa_log, glib log), formatting the message and
then printing it. For printing to the journald, we still use the glib
message handler, converting all the needed fields to GLogField on demand.
That message handler does not do any checks for the topic or the level, so
we can just call it to send the message.
Also rename the intermediate lua api table WpDebug -> WpLog
Keeps things more consistent with the function names (wp_log*),
with the lua api (Log.*) and with pipewire using log.{h,c} as well.
After all, these functions are for logging...
