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.
On Exherbo we allow to install different Lua ABIs in parallel and
users can choose per-package which Lua ABI to use, e.g.
media/wireplumber LUA_ABIS: -* 5.3
However, wireplumber's build system doesn't provide a way of explicitly
requesting a specific version, which makes the build non-deterministic,
since you get a different result if you install today with Lua 5.3
installed and reinstall tomorrow after installing Lua 5.4.
To fix this, I introduced a `system-lua-version` option that allows to
specify an explicit Lua version to check for and build against:
> $ meson .. -Dsystem-lua=true -Dsystem-lua-version=5.4
> The Meson build system
> Version: 0.58.0
> Source dir: /mnt/development/scm/freedesktop/wireplumber
> Build dir: /mnt/development/scm/freedesktop/wireplumber/build/reconfigure
> Build type: native build
> Project name: wireplumber
> Project version: 0.4.1
> [...]
> Run-time dependency lua-5.4 found: YES 5.4.3
> [...]
> Build targets in project: 56
>
> wireplumber 0.4.1
>
> Lua version : 5.4.3 (system)
> systemd conf data : YES
If the specified version isn't found, the build will fail loudly:
> $ meson .. -Dsystem-lua=true -Dsystem-lua-version=5.5
> [...]
> Found CMake: /usr/host/bin/cmake (3.20.5)
> Run-time dependency lua-5.5 found: NO (tried pkgconfig and cmake)
> Run-time dependency lua5.5 found: NO (tried pkgconfig and cmake)
>
> ../meson.build:50:6: ERROR: Problem encountered: Specified Lua version "5.5" not found
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.
Previously we had the config file split in pipewire-fashion: CONFIG_NAME for
the filename and CONFIG_PREFIX for the (absolute) config directory the file
resides in. Since we always resolved CONFIG_PREFIX to be an absolute path we
might as well just pass the fully resolved config file to pipewire instead.
This will eventually allow us to have multiple lookup directories.
From the g_file_test documentation:
"For example, (G_FILE_TEST_EXISTS | G_FILE_TEST_IS_DIR) will return TRUE if
the file exists; the check whether it's a directory doesn't matter since the
existence test is TRUE. With the current set of available tests, there's no
point passing in more than one test at a time."
For bindir, libdir and datadir, meson enforces that either
- the value is an absolute path that is a subdir of $prefix
- the value is a relative path that is then made a subdir of $prefix
Example meson error message:
ERROR: The value of the 'bindir' option is '/usr/foobar' which must be a subdir of the prefix '/usr/local'.
Note that if you pass a relative path, it is assumed to be a subdir of prefix.
And meson handles absolute paths for those directories correctly (ignoring
$prefix), so we don't need to manually compose those.
Only exception is sysconfdir which may be outside the prefix but there too
meson handles an absolute path correctly.
Sometimes, especially when running the wireplumber daemon with valgrind, a new
global with the same Id as another old global owned by a proxy wants to be
exposed before the old proxy is destroyed. If this happens, instead of returning
with an assertion error, we remove the old global and we export the new one.
Globals can be removed by the object manager when their associated proxy is
currently being bound. Adding extra checks in wp_global_proxy_bin() to return
a transition error avoids binding the proxy when that happens.
