This is just enough to demonstrate that they work - I'm deliberately
not doing a mass change throughout all tests, and we should definitely
not rush to introduce these into production code, because it would
hinder cherry-picking and merging fixes between branches. However,
new code on master can use them freely.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101895
When we listen on a tcp: address we should get a connectable tcp:
address, and so on.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101567
dbus_server_get_address() returns a copy. It isn't clear why.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101567
The GLib functions we're using don't, and it seems to be possible to be
interrupted during cleanup for our tests.
Windows apparently has and uses ENOENT for _unlink(), so just do the
same on Windows there; but EINTR is very much a POSIX thing, so ignore
that on Windows.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99825
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: add Windows fixes from a later commit, also reviewed by Philip]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This makes life easier for frameworks like LAVA that screen-scrape
test results.
g_test_message() is not displayed by default, but each test can be run
with either --tap or --verbose to get these messages displayed.
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89846
We only use dbus-glib for its main loop; within dbus, DBusLoop is
available as an alternative, although it isn't thread-safe and
isn't public API.
For tests that otherwise only use libdbus public API, it's desirable to
be able to avoid DBusLoop, so we can run them against an installed
libdbus as an integration test. However, if we don't have dbus-glib,
we're going to have to use an in-tree main loop, which might as well
be DBusLoop.
The major disadvantage of using dbus-glib is that it isn't safe to
link both dbus-1 and dbus-internal at the same time. This is awkward
for a future test case that wants to use _dbus_getsid() in dbus-daemon.c,
but only on Windows (fd.o #54445). If we use the same API wrapper around
both dbus-glib and DBusLoop, we can compile that test against dbus-glib
or against DBusLoop, depending on the platform.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
