Add a new private header file, wpbuildbasedirs.h, that contains the
build-time base directories passed directly from meson, without
the "wireplumber" suffix.
Use this to set the WP_BASE_DIRS_BUILD_* and adjust the code to honor
the SUBDIR_WIREPLUMBER flag.
This makes things more consistent and allows us also to add more
search paths in the future if necessary.
Also, stop using g_module_build_path() because it's deprecated and
build the path manually. This obviously is not portable to Windows/Mac
or other exotic platforms, but portability is not important at this
point. PipeWire is also not portable beyond Linux & BSD.
Instead, make it so that WIREPLUMBER_*_DIR environment variables can
contain a list of directories to look into. This is safer and,
as a bonus, allows for more control over the lookup directories.
Using the G_TEST_SRCDIR variable can cause problems for tests of other
projects that use libwireplumber and may also lead to unexpected
behavior by not being obvious that this causes wireplumber to skip
looking in its standard directories...
This also brings back WIREPLUMBER_CONFIG_DIR, which is going to be
needed again for the upcoming WpConf changes.
Previously files would be sorted across all configuration dirs
so their filename was all that mattered, not the priority of the directory.
Ex. you could get:
- /etc/wireplumber/10-foo.conf
- /usr/share/wireplumber/20-bar.conf
- $XDG_CONFIG_HOME/wireplumber/30-baz.conf
- /usr/share/wireplumber/40-zzz.conf
This commit changes that so that it follows the hirerachy of the directories
first and then the order of the filenames, starting from the lowest priority
directory. So now for the same files you get:
- /usr/share/wireplumber/20-bar.conf
- /usr/share/wireplumber/40-zzz.conf
- /etc/wireplumber/10-foo.conf
- $XDG_CONFIG_HOME/wireplumber/30-baz.conf
In addition, the hash table is avoided, making things a bit more efficient
and the files are checked for G_FILE_TEST_IS_REGULAR
Shadowing of files still works the same, so in the above example
if /etc/wireplumber/30-baz.conf also exists, it is not returned
in the list, because it's shadowed by $XDG_CONFIG_HOME/wireplumber/30-baz.conf
* 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.
Since the wireplumber configuration has been moved to /usr/share/pipewire, it
does not makes sense to have a different path for the WIREPLUMBER_CONFIG_DIR
environment variable. Therefore, the WIREPLUMBER_CONFIG_DIR environment variable
has been changed to just be an alias of PIPEWIRE_CONFIG_DIR. Finally, Lua
scripts are now installed under /usr/share/wireplumber/scripts instead of
/usr/share/pipewire/scripts as they are a wireplumber feature only.
There is no need to have this as an optional module, since libintl
is a hard dependency of both PipeWire and GLib. This way we can keep
things a bit simpler and faster (no string copies and plugin lookups)
Bump meson dependency to 0.59 to benefit of the libintl lookup that
is now built into meson's dependency() function.
pw_log_set resets the log level of the logger to the Pipewire's current
level. Here, it's instead expected that the level is retained, so call
pw_log_set_level first.
It used to be that pw_init set the log level based on PIPEWIRE_DEBUG
value, but this is now done only when using Pipewire's default logger.
It's not used elsewhere, so there is no good reason yet to expose it.
Besides, I expect that GLib will likely add a method in the future
to return the XDG_STATE_HOME (which is relatively new in the xdg spec)
* Make the flags public and give them nicer names
* Pass down the flags from the caller, so the caller can now explicitly
ask for looking into specific directories
* Rename the methods
* Remove and inline the wp_get_xdg_config_dir() method, since it's only
used internally
* Refactor the lookup dirs ordering to get both WIREPLUMBER_*_DIR env
variables to replace all the other directories. Previously, we were looking
for scripts in WIREPLUMBER_DATA_DIR, but we were also looking in /etc at
the same time (with precedence, even), which could result in unexpected
behaviour. Now, if a WIREPLUMBER environment variable is specified,
we only look in there.
This also corrects the logic of loading config files in m-lua-scripting.
Previously, if an error occured within the iteration function,
the error was not properly propagated to the caller because -EINVAL
was being added to nfiles instead of checked.
The previous approach to loading config files was to ask WP for the
directory and then search those for the config files. This patch changes the
approach - a caller now asks WP to search for a specific config file or
iterate over a config file directory.
This allows us to implement a directory lookup order, i.e.
"wireplumber.conf" may be in XDG_CONFIG_DIR, /etc/,
/usr/share and the first one found is used.
For configuration directories, the new method iterates over all matching
entries (files + directories) and invokes a callback for each entry.
This enables distributions to ship default files in /usr/share/wireplumber
but have admins and users override them on a local basis. For lua scripts in
particular, overriding a distribution-provided file with an empty file
effectively disables it, adding a file adds it in the right sort order.
We have ended up not using them, so let's not carry them
in the ABI of 0.4
We can always revert that, but let's first decide how
these objects should be used
And don't override PIPEWIRE_DEBUG, unless WIREPLUMBER_DEBUG is set.
This allows pipewire to use log.level as well to set up its logging.
If WIREPLUMBER_DEBUG is set, though, override PIPEWIRE_DEBUG to prevent
log.level from being used.
It is inevitable to avoid setting PIPEWIRE_DEBUG, because the
log.level from client.conf will kick in and change the pipewire log
level when the pw_context is created. PIPEWIRE_DEBUG is the only
way to override.
* Use a more complete API to introspect SPA types
* Avoid the need for the Tables enumeration; the tables
are now registered with a string
* Avoid the need for initialization, work directly on spa_types
and other static data
* Allow working with Object pods that are not Params;
the PARAMS table was previously hardcoded in the pod implementation
* Add a different dynamic type registration system, closer to
how spa type works. The only regression is that we can no longer
register additional custom object fields (custom SPA_PROP_* for example),
but this feature can be re-added later
