We need to link the code coverage objects, directly or indirectly,
into every executable and every shared library. The rule I've followed
to make it clear that we do this, without too much repetition, is:
each executable, shared library or convenience library has
CODE_COVERAGE_LIBS in its LDADD or LIBADD, unless it is linked to a
convenience library in the same directory that has CODE_COVERAGE_LIBS
in *its* LIBADD.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We officially release dbus in the form of Autotools `make dist` tarballs,
but people who have downloaded those tarballs should be able to choose
the CMake build system. Our CI should assert that they can.
(The Autotools debug build already does a `make distcheck`, which
asserts that tarball releases can be used for an Autotools build.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: dbus#255
If lists are in a completely arbitrary order, sorting them consistently
means that there is only one correct place to insert a new entry, avoiding
the merge conflicts that would occur if we always append new entries.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Patterns in the top-level .gitignore match in all subdirectories, so
there's no need to repeat ourselves quite so much for generic
C, Autotools and gcov patterns.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't want to set these globally via the normal CFLAGS, because if
we did, AddressSanitizer would catch test-segfault deliberately
segfaulting, and "helpfully" turn it into exit status 1, which in turn
makes our test fail because it asserts that the segfault is reported
as a segfault.
A typical use with gcc as compiler, on a reasonably recent Debian,
would be:
./configure SANITIZE_CFLAGS="-fsanitize=address -fsanitize=undefined -fPIE -pie"
Signed-off-by: Simon McVittie <smcv@collabora.com>
After the merge request !22 was created, this bug was fixed in !23,
the associated branch was used for local tests, but the fix was not
transferred to !22. After merging !22 into the master branch and
rebasing !23 to the master, this fix was lost.
Reviewed-by: Simon McVittie <smcv@collabora.com>
In particular this avoids installing the TeX toolchain.
However, this also means we don't install dbus, which broke some tests
in minimal containers where dbus wasn't already installed, because the
messagebus user wouldn't have been created. Make sure that user exists,
using the same adduser call as the Debian dbus package.
CMake really wants to find a C++ compiler (even though we only use C++
when compiling for Windows), so explicitly install the default
version of the GNU C++ compiler, g++.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The version of gcc in trusty is too old for AddressSanitizer, which we
want to be able to start using, and Travis-CI finally supports Ubuntu
16.04 'xenial' now. This lets us remove some workarounds, but we need
to update others.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This simplifies bootstrapping: now you don't have to build dbus,
build dbus-python (with GLib), and use dbus-python to test dbus.
It also avoids test failures when using facilities like
AddressSanitizer. When libdbus is built with AddressSanitizer, but the
system copies of Python and dbus-python were not, dbus-python will exit
the Python interpreter on load, because libasan wasn't already
initialized. The simplest way to avoid this is to not use Python:
the scripts are not *that* hard to translate into C.
Both of these tests happen to be conditionally compiled for Unix only.
test_activation_forking() relies on code in TestSuiteForkingEchoService
that calls fork(), which can only work on Unix; meanwhile,
test_system_signals() tests the system bus configuration, which is
only relevant to Unix because we don't support using dbus-daemon as
a privilege boundary on Windows (and in any case D-Bus is not a Windows
OS feature, so the system bus cannot be used to communicate with OS
services like it can on most Linux systems).
This is also a partial solution to
<https://gitlab.freedesktop.org/dbus/dbus/issues/135>, by reducing the
size of name-test/.
For this to work, we need to build the test-service helper executable
even if embedded tests are disabled.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This should avoid test failures under CMake in which the
dbus-daemon inherits an unwanted fd from CMake's test framework, causing
the close-on-exec check before executing activated services to fail.
The dbus-daemon now marks all fds that it inherits, except for its
stdin, stdout and stderr, to be closed on exec. For completeness, the
dbus-daemons run by dbus-run-session and dbus-launch also now inherit
stdin, stdout, stderr and the pipes used to communicate with their
callers, but nothing else.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Using xsltproc helps to reduce manual editing of xml doc and avoids
cyclic dependency (kdelibs depends on dbus and dbus depends on kdelibs).
It is available on all platforms (in the opposite to xmlto) and supports
freedesktop CI out of the box.
This commit adds docbook-xml and docbook-xsl as new dependency for cmake
and removes obsolate xmlto support, which depends on xsltproc.
Instead of the previous adaptation of the existing template
for the session bus, a separate template is now used, which
can be more easily adapted to the requirements of the test
applications.
Bug: https://gitlab.freedesktop.org/dbus/dbus/issues/57
Switch the order of the argument checks to avoid the
-Wduplicated-branches warning.
Signed-off-by: David King <dking@redhat.com>
Reviewed-by: Simon McVittie <smcv@collabora.com>
Travis-CI workers have cmake preinstalled, but Gitlab-CI Docker images
typically don't.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108177
Acked-by: Philip Withnall <withnall@endlessm.com>
This was the only remaining symbol using the long prefix. Renaming it
gives us one consistent rule: symbols starting with dbus are public,
symbols starting with _dbus are not.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107349
Reviewed-by: Thiago Macieira <thiago@kde.org>
Everywhere that we want GLib, we also want GObject and GIO. Detecting
GLib and GIO but not GObject makes very little sense anyway, because
GIO depends on GObject.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105521
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
