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>
va_copy is not an ordinary function (an extern symbol), so we can't
treat it as one. Instead, use the same compilation/linking check as
in the Autotools build system.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
[smcv: Rename to avoid using "Win32" to refer to both 32- and 64-bit]
Signed-off-by: Simon McVittie <smcv@collabora.com>
When building for Windows, either natively or cross-compiling and
running tests with Wine, test-autolaunch-win expects to be able to
find the just-built dbus-daemon.exe in the PATH.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This would currently result in a hard dependency on Valgrind headers
when linking dependent projects to libdbus (see
https://github.com/mesonbuild/meson/pull/10544 for an attempt to
avoid this), so distributions likely don't want to enable this feature
in their main builds of valgrind (although they could enable it in
special debug builds like the one in Debian's dbus-tests package if
desired).
Signed-off-by: Simon McVittie <smcv@collabora.com>
At the time we do this check, version_script has not yet been generated,
so we have to use something else.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The built-in atomic intrinsics are not exactly functions, so it's
incorrect to use has_function to check for them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The other build systems don't define this, and it's too confusing to
have both DBUS_ENABLE_ASSERTS and DBUS_ENABLE_ASSERT.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Group slow tests (those taking about a minute or more in one of the
configurations built on Gitlab-CI) into a new 'slow' suite, which can
be used with `meson test --no-suite=slow` to run just the faster tests.
They default to a 5 minute timeout (usually enough) unless overridden
(bus/dispatch.c can be *very* slow when OOM testing is enabled, and
gets a 30 minute timeout).
For the remaining tests, default to Meson's usual 30 second timeout,
but bump up the timeout a bit in some cases to have a safety margin
(my method was to take the slowest run on our Gitlab-CI, and make sure
we're allowing about 3 times that long).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Recent versions of valgrind have library code, which we don't need (or
want) to link to; all we actually want is <valgrind.h> and <memcheck.h>.
I had hoped that this would suppress the Requires.private when
generating our .pc file, but it doesn't seem to.
Signed-off-by: Simon McVittie <smcv@collabora.com>
