Valgrind tests are running under different conditions than normal tests,
specifically they all run in the same process rather than running one
fork per test. This means one test can affect another test's result if
the test doesn't clean up propertly.
This makes them harder to debug from the logs, so let's give us a
fighting chance by having debug logging enabled.
When running meson test without a preceding ninja build, we end up with
missing libraries. This somehow happened to work until recently but now
it triggers an issue with libspa-dbus.so not being available during the
valgrind test run, causing a test case to fail.
Add a struct spa_log_topic that allows for logical grouping of messages.
The new macros spa_log_logt() and spa_log_logtv() take a topic as
argument, the topic's level acts as filter.
A new macro spa_log_topic_init() initializes a topic. By default a topic
inherits its logger's debug level but a logger implementation may set
that topic to a specific fixed log level.
The various spa_log_*() macros transparently wrap new and old
implementations:
- if the implementation is version 0, the new logt() calls drop the
topic and get routed into the old log() calls
- if the implementation is version 1, the old log() calls use a NULL
topic and get routed into the new logt() calls
All spa_log_* macros use the SPA_LOG_DEFAULT_TOPIC topic (NULL), it is
up to the caller to redefine that. Alternatively, use spa_logt_* to pass
an explicit topic.
There is one crucial flaw in this implementation: log topics are
initialized to their target level by the current logger. Where a topic
is initialized but the logger is switched later, the topic is not
automatically re-initialized. Ultimately this shouldn't matter for
real-world use-cases.
For SPA libraries that we link against elsewhere in the tree, declare a
declare a dependency "foo_dep" for that library that specifies how to
link to it. Then use that dependency in the various targets.
This removes the knowledge of how to link with the library from the
target which can treat it as just another dependency.
In the case of optional libraries (e.g. the journal support lib) we can
then use declare_dependency() to declare an empty dependencies and thus
link them unconditionally in the target.
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
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.
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.
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.
