To achieve comparable results with Meson, the test environment should
provide the same set of environment variables when used in the source
code or the test environment.
Resolves: dbus/dbus#541
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Previously, the CMake build enabled tests by default, and enabled both
modular and intrusive (embedded) tests with a single option. This is
a really bad idea if anyone is using CMake-built binaries in production.
DBUS_BUILD_TESTS now enables only the modular tests, which are safe to
enable in production builds.
A new DBUS_ENABLE_INTRUSIVE_TESTS option enables the intrusive test
instrumentation.
To preserve existing test coverage, explicitly enable the intrusive
tests in most CMake-based Gitlab-CI jobs (Debian native, openSUSE native,
Windows).
In jobs that have a mirrored pair of production/debug builds (openSUSE
and Debian mingw32/mingw64 cmake), instead we leave the production
build as-is and only build full test coverage in the debug build.
Co-authored-by: Philip Withnall <philip@tecnocode.co.uk>
Signed-off-by: Simon McVittie <smcv@collabora.com>
These environment variables are used by GLib's g_test_build_filename()
and related convenience functions, which make it easier for unit tests
to find data files in a way that works for both build-time tests and
"as-installed" tests. During "as-installed" testing, both variables
will normally be unset, and GLib uses the directory containing the
executable. In most cases that results in the right thing happening, and
this will also be true for dbus, since we install the test executables
in ${libexecdir}/installed-tests, helper executables in the same place,
and test data in ${libexecdir}/installed-tests/data.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it possible for projects to incorporate D-Bus as a CMake sub-project in a larger CMake project.
Before this PR, doing so would result in many errors.
This is because CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR would point to directories above the D-Bus project.
Using paths relative to the project directory, PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR, corrects for this.
Unsupported warnings are detected by cmake through errors during
compilation, which causes g++ not to detect them, since they are
only output as warnings. Setting -Werror ensures this.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
I am compiling for FreeBSD where the compiler is Clang and doesn't accept
all the GCC warning flags. This breaks the -Werror build:
```
error: unknown warning option '-Wduplicated-branches' [-Werror,-Wunknown-warning-option]
error: unknown warning option '-Wduplicated-cond' [-Werror,-Wunknown-warning-option]
error: unknown warning option '-Wjump-misses-init' [-Werror,-Wunknown-warning-option]
error: unknown warning option '-Wlogical-op'; did you mean '-Wlong-long'? [-Werror,-Wunknown-warning-option]
error: unknown warning option '-Wrestrict' [-Werror,-Wunknown-warning-option]
error: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Werror,-Wunknown-warning-option]
```
With this change we use check_{c,cxx}_compiler_flag to check if the flag
is supported before adding it. In the future this will allow adding
clang-specific warning flags to the list of warnings as well since they
will be ignored for GCC.
Previously, only the Autotools build system could do this. This commit
includes most of the same features as in the Autotools build, although
not the user-session semantics, which will be added separately.
Systemd support is controlled by the cmake variable ENABLE_SYSTEMD, which can
have the values OFF, ON and AUTO, the latter enabling support by default if
the required libraries are available.
With WITH_SYSTEMD_SYSTEMUNITDIR a custom installation location can be specified.
If it is not specified, the related install path is determined from the installed
systemd package, if present.
Qt help files are used by Qt Creator and KDevelop, for example, to support
the development of Qt-based applications and libraries.
Generating api documentation in Qt help format is controlled by two
user specific options named --enable-qt-help and --with-qchdir (autotools)
and -DENABLE_QT_HELP and -DINSTALL_QCH_DIR (cmake).
The ctest application is usually not installed in the dbus build
directory. If an older dbus library is contained in this path, it will
be used instead of the currently built one, which can lead to runtime
errors (e.g.: c0000139) if the internal dbus API differs.
This patch introduces a new cmake macro add_session_test_executable,
which uses dbus-run-session to start a dbus-daemon process with a
temporary session bus in the background and the desired client file.
add_session_test_executable requires additional environment variables
defined in the top level CMakeLists.txt.
Bug: https://gitlab.freedesktop.org/dbus/dbus/issues/135
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
If this variable is set, ctest uses wine to run cross compiled
test applications. Otherwise, they are assumed to run on a native
Windows operating system.
The new cmake variables Z_DRIVE_IF_WINE and TEST_WRAPPER have been
added to support this function.
The case occurred during test-pending-call-dispatch. To avoid further
applications being affected in the future, the manifest is added to
all test applications.
Windows Error 740 is defined as 'The Requested Operation Requires Elevation'
Previous cmake versions seemed to be more tolerant.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Simon McVittie <smcv@collabora.com>
The recent implementation generates a timestamp containing eol on
linux hosts, which generates unparseable versioninfo.rc.
This commit raises the minimal required cmake version to 3.0.2.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Reviewed-by: Simon McVittie <smcv@collabora.com>
We have to skip the GetMachineId() part during build-time testing
if it wouldn't work - there is no guarantee that dbus has ever been
installed on the build system. However, we can insist on it during
installed-tests, if we make sure to complete the installation for the
Travis-CI build by running dbus-uuidgen.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101257
This avoids "capturing" the build directory in the built binaries
when built with embedded tests, which is good for reproducible builds.
See <https://reproducible-builds.org/> for more information.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100692
Instead of using $DBUS_USE_TEST_BINARY to control whether to use the
hard-coded test binary TEST_BUS_LAUNCH_BINARY, we can just use
$DBUS_TEST_DBUS_LAUNCH to control what we launch directly, as we
were already doing for $DBUS_TEST_DAEMON.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
It is now possible to use msvc warnings identifiers
(e.g. '4114') or gcc warnings keys (e.g. 'pointer-sign').
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93069
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
For GLib-based tests it's useful, because it means g_test_message()
gets logged. For the embedded tests it's now accepted and ignored.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
In general, I think developers running the tests would expect
them to terminate rather than hanging. Developers who want to debug
such an abort by attaching a debugger to a live process can still set
DBUS_BLOCK_ON_ABORT in the environment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41252
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The new macros add_test_executables and add helper_executables provides a
platform independent way for specifing dbus test and service applications.
On native Windows and Linux/UNIX systems the test applications are
directly runable.
When cross compiling for Windows on Linux test applications could be
executed on the Linux host system with the help of wine and activated
binfmt_misc support for wine.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41252
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
