If we don't have the capability to ptrace, we are probably running inside a
container, not the debugger. Check this first so we don't disable forking
mode.
Make this conditional on libcap - where libcap is not available always assume
we *do not* have a debugger attached. This is easier than telling everyone who
runs the tests in a confined system to install libcap.
Fixes#1285
This seems to be a leftover from the autotools conversion but it
does not provide huge benefits. Meson's default behavior is to generate a
header like this, the main advantage of a config.h.meson header is to *filter*
things that should show up in the config.h file. That comes at the cost of
having to #mesondefine every single variable we want.
In most cases, it's easier with meson to just use different configuration_data
objects instead - which we do for most of the code.
The new header file is identical to the old one, discounting comments, sort
order and the following #defines that didn't end up in the config.h before:
HAVE_STRNDUPA
HAVE_STDDEF_H
Use this for the version.h file so we enforce that being used everywhere
instead of accidentaly relying on whatever ends up in config.h.
The generated version.h file is identical.
Drop the Apple-specific defines from config.h.meson - this was never true in
the meson build anyway as nothing set the AC_APPLE_UNIVERSAL_BUILD and the
else condition only undef'd WORDS_BIGENDIAN if... it was not defined.
Drop this and replace it with a meson endian check. There is only one source
file that checks for this #define in spa/plugins/alsa/acp/compat.h, let's hope
nothing breaks here.
Properly escape the keys because we're trying to generate
valid JSON.
Always place ',' after items.
Add a flag to add a '\n' before each item.
Don't try to string-encode the value when it's already a string.
Load and parse config files in the following order:
$PIPEWIRE_CONFIG_DIR or /usr/share/pipewire
/etc/pipewire
$XDG_CONFIG_DIR or ~/.config/pipewire
This ensure we always load a working base config and reduce the
chances of failing because of a back user config file.
The user config file now only needs to contain the section that
needs the be changed.
See #207
Move the spa tests to the pwtest framework. The pod tests have only been
wrapped in the function callers, they don't use the variuos pwtest helpers -
too much work for very little gain here. Can be done incrementally if needed.
Note that this removes the spa tests from the installed tests. Arguably,
installing those tests was unnecessary anyway since they are static binaries
and don't load anything. So having them installed runs the same tests as
having them run in the source tree.
Goal for the pwtest framework is to allow for installed tests, just not there
yet.
Having a helper aids with the file being in the right directory and cleaned up
automatically on exit. Plus, failing the test with the sytem error status code
signals that it's not the actual test failing here.
Helper function to load a SPA interface. This enables a test to easily load a
specific interface and run tests against that interface without having to
instantiate a whole pipewire daemon.
On startup, create /tmp/pwtest-$TIME-$RANDOM/ and give each test an
XDG_RUNTIME_DIR and TMPDIR inside that (simply numerically numbered). This
avoids the tests interfering with the system like accidentally connecting to
the real pipewire instance or trying to create files where they shouldn't.
Heavily inspired by libinput's litest framework (built around check), this is
a from-scratch framework that simplifies adding tests for various parts of
pipewire. See the pwtest.h documentation for details but the basics are:
- PW_TEST() and PWTEST_SUITE() specify the tests to be run
- Test are run in forked processes, any errors/signals are caught and printed
to the log
- Tests have a custom pipewire daemon started on demand to talk to [1]. The
daemon's log is available in the test output.
- Output is YAML to be processed into whatever format needed
[1] There are limits here, since we can't emulate devices yet there is only
so much we can rely on with the daemon.
If we have a C++ compiler, compile all the #include tests with that - it'll
pick up any issues that a C compiler will pick up anyway. This saves us from
having a separate C++ compiler test and it'll test each header separately for
C++ compatibility..
