The function declaration can be moved to system-agnostic header and be
implemented on Windows in following commits.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This can simplify error handling in many situation where a socket is
returned, such as in the following commits.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
PF_UNIX is an old BSD 4.x relic, and even there they promise that PF_UNIX
is the same as AF_UNIX. (Linux socket(2))
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The X11 connection is opened and never closed. Because dbus-launch
forks and continues to run non-trivial code in a forked child, it is
not clear whether (or where) it would be safe to close it; instead, we
leave it open until process exit, at which point the socket is cleaned
up by the kernel.
Any memory allocated for the X11 connection is only allocated once per
run of dbus-launch, so there's no need to keep track of it, and we can
silence these memory leak warnings as uninteresting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise, we'll miss symbols that only appear when _GNU_SOURCE is
defined, like environ in Linux unistd.h.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This turns off a poorly-supported feature of older compilers. Even when
using an older compiler, we want to behave more strictly.
The Autotools build already did this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We know that dbus is not fully strict-aliasing-compliant. In Autotools
we got this from AX_COMPILER_FLAGS_CFLAGS.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We have to set up feature-flag options like _GNU_SOURCE before we
do compiler checks like cc.has_header_symbol, otherwise we'll miss
symbols that are guarded by a feature-flag test, like environ in Linux
unistd.h.
However, we don't want to pass flags for extra compiler warnings
when doing these checks, because that can cause false negatives:
in particular, Meson's check programs nearly always trigger -Wunused.
So the warnings need to be in a separate list.
Signed-off-by: Simon McVittie <smcv@collabora.com>
With Meson 0.63.0, detailed output of TAP tests is not logged, and the
test deadlocks if the stderr pipe fills up. I'm hoping this will be fixed
before 0.63.1, but in the meantime we can work around it by falling back
to the 'exitcode' protocol: this means we lose machine-readable detailed
test results, but at least our tests pass.
See https://github.com/mesonbuild/meson/issues/10577 and
https://github.com/mesonbuild/meson/issues/10563 for details of the
Meson regression.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Newer versions of Meson require the script for a run_target() to be
present at configure time, even if the script isn't run.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we don't do this, Meson will build everything that is a direct
dependency of the test executables, but it won't build indirect
dependencies like GLib's gspawn-win32-helper.exe.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we are not using Meson subprojects, this will have no practical
effect, because the directories won't exist.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The Windows image has expat and zlib installed, but they're 64-bit DLLs
which won't link successfully into our 32-bit build.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't currently know the equivalent of python3-mallard-ducktype on
other OSs like openSUSE, but we know this should work on Debian (it does
when we do Autotools builds).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The whole point of these tests is that they're safe to enable because
they don't affect the production binaries.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These pass a lot of configure arguments taken from RPM macros, which
are only accepted by the meson command if we don't explicitly select
a mode.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is similar to what we have done for CMake since dbus/dbus!87
(commit 1063bba "CI: Do the CMake native debug build from an Autotools
`make dist`"). Our official source releases are Autotools `make dist`
tarballs, so our CI should assert that such tarballs contain everything
necessary to do a CMake or Meson build, so that downstream distributions
using our tarballs as source can choose their preferred build system.
When the Meson build system is ready to be recommended as more preferred
than Autotools, we can do as GLib did: stop releasing `make dist`
tarballs, and start releasing `meson dist` tarballs instead (which will
change nothing for Meson or CMake users, but Autotools users will have
to run autoreconf or autogen.sh before building).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This will make it easier to capture log files. All our CI builds happen
in an expendable checkout, so we can safely remove and re-create ./build.
Signed-off-by: Simon McVittie <smcv@collabora.com>
