MSG_NOSIGNAL could theoretically be an enum member or something rather
than an #define, so it's better to check for the flag defined by the
configure check (as is done in dbus-connection.c already).
Reviewed-by: Colin Walters <walters@verbum.org>
Reviewed-by: Scott James Remnant <scott@netsplit.com>
Since SIGPIPE is no longer touched by default when MSG_NOSIGNAL is
available, it's extra-critical that all socket writes actually pass
that flag.
Signed-off-by: Will Thompson <will.thompson@collabora.co.uk>
This reverts commit 4626b40560.
test-autolaunch works fine in non-launchd environments (and non-X11
environments, based on a quick test passing enable_x11=no to configure).
On the contrary: this commit *broke* the build on non-launchd
environments, because test/name-test/run-test.sh still tried to run this
test even if it hadn't been built.
The excellently-titled commit 197bef8 “Fix test failures on OSX.” broke
the tests on Linux, since there's no wheel group on this side of the
tracks. So here's a group everyone should enjoy.
(If anyone comes along and tells me that DragonflyBSD doesn't have
'nogroup' …)
This patch enables support for Mac OS X's launch daemon
for startup as well as sharing of the DBus session bus
environment. It includes a LaunchAgent plist for automatic
start of the session bus.
* test/name-test/test-autolaunch.c: New file,
unsets DBUS_SESSION_BUS_ADDRESS so we should
fall back to autolaunch:.
* test/name-test/run-test.sh: Run it.
* test/name-test/Makefile.am: Build it.
Rather like "arg0path='/foo/'" matching all object paths starting with
"/foo/", this adds support for matching a prefix of a string argument
with "arg0namespace='org.freedesktop.Telepathy.Client.'" (for example).
This is mostly intended for use with NameOwnerChanged and
PropertiesChanged; thus, only matching the 0th argument is permitted.
(This also means it could work with the multicast-plus-socket-filters
model being considered for DBus-in-the-kernel without having to hash
every period-separated prefix of every string argument.)
The code for accessing services requires absolute pathes, which are based
on DBUS_DATADIR. DBUS_DATADIR on windows is defined relative. This patch
makes sure that those pathes are absolute.
The problem seems to be a race condition with winsock's
internal threads for the non-blocking mode of the sockets,
but I haven't had time to try a standalone test case yet
to confirm it. Anyway, I found a workaround that fixes it
in all cases, so it's good enough for now.
