• Simon McVittie's avatar
    Merge tests' cmake and autotools bus configuration · e9f0378b
    Simon McVittie authored
    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: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
    Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
    Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41222
    e9f0378b
dispatch.c 137 KB