This is in preparation for moving the file: our commit hook would
object to the delete + add otherwise.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is in preparation for moving the file: our commit hook would
object to the delete + add otherwise.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This required exposing one additional internal symbol:
_dbus_hash_table_ref(). I think that's a reasonable trade-off for not
compiling this test into the library.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it easier for a developer to run just the fast parts while
debugging some issue reproduced by the faster tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Now that there is no code outside test/ that calls into this, we can
move it into test/, reducing the size of libdbus.
dbus-test-tap.[ch] still need to stay in dbus/ as long as there is
code in dbus/ or bus/ relying on them, and also need to be linked into
libdbus as long as there is other code in libdbus relying on them,
so they stay where they are for now. Similarly, dbus-tests.h lists
the tests that are still embedded in libdbus, and must stay where
it is for the moment.
With this move, various tests now need to be linked to the dbus-testutils
convenience library.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The -test suffix does not indicate that this is a test, but rather that
it is for tests (similar to the -unix and -win suffixes on modules like
dbus-sysdeps). This seems unnecessarily confusing, so rename it to end
with -for-tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This groups them with the rest of the tests, and enables parts of
the test code to be unembedded from libdbus and moved to test/ too.
Rename the executable to test-misc-internals, not test-dbus. The name
test-dbus made some sense as "the executable that contains the code in
dbus/", but makes a lot less sense in test/: dbus is the name of the
entire project, so this test has no particular special claim to that
name. test-libdbus doesn't seem right either, because all the tests
exercise libdbus one way or another.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This groups them with the other tests, and avoids having them influence
the test coverage stats in bus/.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is in preparation to move some of this code into the test/
directory. I've ignored changes that appear to be trivial.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This test is sufficiently well-separated that there's no real need
to embed it in libdbus. Move it into the test directory instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This means we can share them between tests without having to compile
the same file repeatedly, and makes them easier to share between
directories when we move test executables into test/.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As far as I can tell, the only significant contributions have been
from Red Hat and Collabora, both of which have given permission to
relicense their parts of the dbus codebase to MIT/X11; so let's go
with that.
I'm assuming here that tree-wide changes from
_DBUS_GNUC_WARN_UNUSED_RESULT to _DBUS_WARN_UNUSED_RESULT, and tree-wide
changes to how we include config.h, are not significant for copyright
purposes.
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
We want to make autoconf fail early and with a user-comprehensible
message if autoconf-archive isn't installed, rather than generating
a configure script with syntax errors, or a configure script that runs
successfully but doesn't do what we intended.
However, autoconf-archive doesn't actually guarantee not to use
AX_-prefixed shell variable names without m4_pattern_allow'ing them
(unlike Autoconf, Automake, Libtool and pkg-config, which explicitly use
m4_pattern_allow for variables with AC_, AM_, LT_ and PKG_ prefixes), so
it isn't safe to assume that they won't be used. In particular, recent
versions of AX_CHECK_GNU_MAKE appear to be using
$AX_CHECK_GNU_MAKE_HEADLINE as a shell variable.
Instead, specifically forbid the names of the finite list of macros
that we actually use.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: dbus#249
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.
Rename structure DBusSocketSet to DBusPollableSet and adjust the corresponding functions/files
See merge request dbus/dbus!81
Reviewed-by: Simon McVittie
Now that we start the spawned program from the main thread, there
is no need to wait for it before dereferencing `sitter->child_handle`.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Since the child program is started in the main thread, there is no
need to pass a copy of argv to the thread waiting for the child's
termination.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
It's unexpected for a function to take ownership of its arguments
without indicating that in its name, or at least documenting it.
The only caller with envp != NULL is in
bus_activation_activate_service(), which has been updated.
Based on part of a larger commit by Ralf Habacker.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We would like to stop taking ownership of envp, but we can't do that
without a deep copy if a different thread might still be using it
(asynchronously) after the main thread has returned from
_dbus_spawn_async_with_babysitter().
Originally part of a larger commit by Ralf Habacker.
Signed-off-by: Simon McVittie <smcv@collabora.com>
While writing the wording to deprecate XML policy installed by packages
into ${sysconfdir}, I realised we didn't give a typical example of
what packages *should* do.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Now that dbus 1.10 has become widely available, we should start to
treat ${sysconfdir} as reserved for the sysadmin, and encourage
third-party software packages to install their integration files into
${datadir}.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Multi-configuration generators (VS, Xcode) append a per-configuration
subdirectory to the specified CMAKE_xxx_OUTPUT_DIRECTORY} directory.
To use the real output paths in test applications, this subdirectory
must be added to the corresponding cmake variables.
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>
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>
Instead of the variables EXECUTABLE_OUTPUT_PATH and
LIBRARY_OUTPUT_PATH, which have become obsolete since
cmake 3.x, CMAKE_xxx_OUTPUT_PATH is now used to define
output paths in the build directory.
It is not safe to assume that the result of getenv() is not invalidated
by a subsequent call to setenv(), and dbus#240 demonstrates that this
can be a problem in practice when running Windows code under Wine.
Closes: https://gitlab.freedesktop.org/dbus/dbus/issues/240
Signed-off-by: Simon McVittie <smcv@collabora.com>
This all seems to have been written by Red Hat or by Collabora, so we
have permission to relicense it under the MIT/X11 license, and we
might as well do so.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This results in one less special case in test-main, which will be
significant when we want to make the tests more data-driven.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This will make it possible to unify the wrapper code that runs them.
I'm using a plain C string rather than a DBusString to make it
more straightforward to carve out tests into their own executables.
Signed-off-by: Simon McVittie <smcv@collabora.com>
