Each component can now list required and optional dependencies,
using the component feature names to match other components.
In addition, each component feature can be declared as required, optional
or disabled, making optional components easier to deal with.
The component flags (ifexists, nofail) have been removed.
Using virtual components, this system also allows easier customization
of which components should be loaded for a specific configuration,
without requiring the user to copy the list of components and edit it.
Also bump the required glib version to 2.68 for g_assert_cmpstrv()
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.
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.
Timeout of 3 seconds is too slow for test-si-standard-link on slower
devices, crank this up with plenty of extra margin. Does not
practically affect running time on faster devices.
- settings.c tests conf file loading & parsing, metadata updates,
wpsetttings object creation and its API.
- settings.lua tests the API from lua scripts.
- Add a sample settings.conf file, this file contains sections copied
over from client.conf along with the settings section. Add a file
each for wp side and lua side of scripts.
- Make changes in base test infrastructure to take a custom conf file.
- Enhance the wp_settings_get_instance_api() to be take metadata_name
parameter. So, Wpsetttings is now a singleton instance for a given
metadata file.
- Enhance the m-settings module also to be take metadata_name parameter.
this is handy for lua side of tests as its cumbersome to do this is
lua.
Until now, object manager could only match pw global properties on
pw global objects, because this is the only available properties set
at the time the registry creates the global.
With this change, the object manager will now bind the proxy
if the type and the pw global properties have matched and will wait
until the proxy is available with all of its properties and tries
the check again.
This adds WP_SESSION_ITEM_FEATURE_ACTIVE and WP_SESSION_ITEM_FEATURE_EXPORTED
features, so _activate and _export APIs have been removed. Modules and unit
tests have also been updated.
It can be a bit tricky because the "installed" signal may be fired
from inside the context of wp_core_install_object_manager(),
in which case the main loop should not be executed (or it will never quit)
