On Unix, the connect address should basically always be "autolaunch:"
but the listen address has to be something you can listen on.
On Windows, you can listen on "autolaunch:" or
"autolaunch:scope=*install-path", for instance, and the dbus-daemon is
involved in the auto-launching process.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38201
Reviewed-by: David Zeuthen <davidz@redhat.com>
[default address changed to autolaunch: for interop with GDBus -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The system bus is unsupported (and rather meaningless) on Windows anyway,
so we can use anything. Also, make it clear that it has to be a
"specific" address that can be listened on *and* connected to,
like unix:path=/xxx - a listen-only address like unix:tmpdir=/xxx or
nonce-tcp: would not be suitable.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38201
Reviewed-by: David Zeuthen <davidz@redhat.com>
On Linux, this is libpthread; on other Unixes, in principle it might be
called libpthreads or libthreads or something.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=47237
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
cmake and autotools session bus configuration templates are identical,
so cmake now uses the autotools.
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41319
According to Ralf, there's no standard name for this in CMake, so we
might as well use the standard Automake name.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41222
In Unix, the tests listened on both debug-pipe (which is a socketpair,
or a TCP emulation of socketpair on Windows) and a Unix socket.
In the Windows port, the tests were hard-coded to listen on a particular
port, which allowed the dispatch test to connect to that port, as long
as no two tests ran simultaneously (which I don't think was ever guaranteed -
make -j can violate this). That's valid out-of-process, and also
fully-specified, so they only needed one <listen> directive, so the
CMake input only had one.
To make the tests work under CMake on Unix, there was a hack: the string
substituted for the content of the <listen> directive contained
</listen><listen> to get the other address in, which is pretty nasty.
Instead of doing that, I've made both build systems, on both Unix and
Windows, use both debug-pipe and a more normal transport (Unix or TCP).
debug-pipe has a Windows implementation and it's used in
dbus-spawn-win.c, so it'd better work. The use of debug-pipe is now
hard-coded rather than being a configure parameter (there's no reason
to vary it in different builds), and I used TEST_LISTEN as the name of the
Unix/TCP address, because it's a "vague" address (no specific Unix path, no
TCP port), that you can listen on but not connect to.
This in turn means that we can merge the Autoconf .in and CMake .cmake
files, similar to Bug #41033.
You might wonder why I've kept debug-pipe. I did try to get rid of it, but
it turns out that the tests in dispatch.c rely on
dbus_connection_open_private() not blocking, and normal socket
connections block on connect(). Until we fix that by adding an async
version of dbus_connection_open_private(), it won't be safe to have a
test like dispatch.c that "talks to itself", unless it uses a transport
as trivial as debug-pipe in which neither end has to block on the other.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41222
Also use EXEEXT in all the service files, even in the automake build
system.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41222
Find either expat or libxml2 xml parser libraries, depending on -DDBUS_USE_EXPAT=ON|OFF
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41027
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If the C library is (e)glibc, this allows use of POSIX, BSD, SVID, GNU,
etc., extensions to ISO C, regardless of using -ansi or not.
Not doing this broke the cmake build on Linux since commit 18b08180,
which added AC_USE_SYSTEM_EXTENSIONS to configure.ac (and removed
_GNU_SOURCE from files that use it) without also updating the cmake
build system. SO_PEERCRED is defined unconditionally, but struct ucred
is considered to be a GNU extension, so can't be used under _GNU_SOURCE.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=29228
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
This is the library used by tests that link libdbus-internal and DBusLoop.
By linking libdbus-internal into it, we can avoid having to repeat that
dependency all over the place - libtool and cmake both know how to follow
recursive dependencies.
In cmake, also use libdbus-testutils for more tests, in preference to
repeating its source files.
