-
Simon McVittie authored
This simplifies bootstrapping: now you don't have to build dbus, build dbus-python (with GLib), and use dbus-python to test dbus. It also avoids test failures when using facilities like AddressSanitizer. When libdbus is built with AddressSanitizer, but the system copies of Python and dbus-python were not, dbus-python will exit the Python interpreter on load, because libasan wasn't already initialized. The simplest way to avoid this is to not use Python: the scripts are not *that* hard to translate into C. Both of these tests happen to be conditionally compiled for Unix only. test_activation_forking() relies on code in TestSuiteForkingEchoService that calls fork(), which can only work on Unix; meanwhile, test_system_signals() tests the system bus configuration, which is only relevant to Unix because we don't support using dbus-daemon as a privilege boundary on Windows (and in any case D-Bus is not a Windows OS feature, so the system bus cannot be used to communicate with OS services like it can on most Linux systems). This is also a partial solution to <dbus/dbus#135 >, by reducing the size of name-test/. For this to work, we need to build the test-service helper executable even if embedded tests are disabled. Signed-off-by: Simon McVittie <smcv@collabora.com>
1191262f