These were in git but not distributed in source tarballs, and in fact
not hooked up to the Autotools build system at all.
test/data/valid-introspection-files was mentioned in the CMake build
system (copied from the source directory to the build directory), but
according to `git grep` is not used for anything.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103420
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>
If __LINE__ doesn't work in MSVC's resource compiler, then removing
the #line directive altogether seems a simpler fix than redefining
__LINE__ to the wrong value.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The resource file used to #include this, but it was unnecessary,
and Ralf removed it in commit e3a14eb.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This is nicer for cross-compiling, because AC_RUN_IFELSE can't work
there. In practice abstract sockets are supported on Linux since
2.2 (so, all relevant versions), and on no other platform; so it
seems futile to keep this complexity.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34905
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This was presumably once used in constructs like
"unix:" DBUS_PATH_OR_ABSTRACT "=/var/run/dbus/foo", but git grep says
there are no remaining uses, so it can go.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34905
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This explicitly sets the execution level to 'asInvoker', preventing
Windows' UAC heuristics from deciding that because its name mentions
"update", it probably needs to escalate privileges.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102558
Reviewed-by: Simon McVittie <smcv@collabora.com>
This feature is now compile-time conditional, and off by default.
pam_console appears to have been in Fedora and Gentoo until 2007.
pam_foreground seems to be specific to Debian and Ubuntu, where it was
unmaintained since 2008 and removed in 2010. The replacement for both
was ConsoleKit, which has itself been superseded by systemd-logind and
ConsoleKit2.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/101629
Reviewed-by: Philip Withnall <withnall@endlessm.com>
By default ${runstatedir} is the same as ${localstatedir}/run, but many
Linux distributions configure it to be /run and mount a tmpfs in that
location. All other factors being equal, it is preferable to use /run
where available because it is guaranteed to be local, whereas traversing
/var might involve automounting a networked filesystem (even though
/var/run itself is very likely to be a tmpfs).
/run or /var/run is currently only used in a few places in dbus, but
I plan to make more use of it during the development of
<https://bugs.freedesktop.org/show_bug.cgi?id=100344>.
The pid file is not part of the API between dbus and other software
(other than distribution init scripts for dbus itself), so we do not
need to keep it strictly compatible; so it is OK to move it.
We do not yet use /run for the system bus socket, because that is
part of the API between D-Bus clients and servers, and has always been
"officially" /var/run/dbus/system_bus_socket.
<https://bugs.freedesktop.org/show_bug.cgi?id=101628> tracks the
possibility of changing that.
Similarly, we do not replace /var/run/console with /run/console, because
that path is part of the API between dbus-daemon and the obsolete PAM
modules pam_console and pam_foreground that used /var/run/console.
<https://bugs.freedesktop.org/show_bug.cgi?id=101629> tracks the possible
future removal of that code path.
In the CMake build system, the equivalent of ${runstatedir} remains
hard-coded to the equivalent of ${localstatedir}/run for simplicity. For
the sort of system-wide installations that would consider redefining
${runstatedir} to /run, the Autotools build system is strongly
recommended: in particular this is what Linux distributions are expected
to use.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101569
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
We haven't supported XML libraries other than Expat since 2013.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69801
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
With this support cmake and autotools generates cmake equivalent of
pkgconfig files on configure time named DBus1Config*.cmake. These
files are installed into the related directory where cmake expects
find_package related config files.
For instructions how to use this feature with clients see readme.cmake.
With previous DBus versions each cmake client using DBus as dependency
needed a related FindDBus*.cmake in its source distribution or in
the cmake binary packages. With the 'config' find package style support
provided by this patch this requirement has been removed.
The generated config file uses pkgconfig on unix or autotools to
fetch package build flags, which is the prefered way. On Windows
we do not want to require CMake users to have pkg-config installed
so it uses cmake buildin target export support for exporting all
targets into DBus1ConfigTargets*.cmake.
[smcv: make sure variable substitution works in Autotools too]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721
Reviewed-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Relocatable pkgconfig files are necessary when using packages installed to
a location that does not match the location for which they were compiled.
However, using ${pcfiledir} is problematic for system installations
in standard locations, because it interferes with pkg-config's
ability to filter out -I, -L options that are redundant with compiler
defaults (which is important if you are trying to use a newer version
of a library than the system copy).
In practice operating system vendors installing dbus to standard
locations use Autotools, so we enable relocatable builds by default
when building with CMake.
For simplicity, we're also not relocatable if the library directory
is something more complicated than lib or lib64 (e.g. under Debian
multiarch); we don't want to have to compute how many ../ to add.
This is non-trivial to determine in an Autotools build, so for now
there is no support for relocation when built with Autotools,
even as an opt-in feature.
Going via the ${original_prefix} variable is because under Autotools,
both ${prefix} and ${exec_prefix} technically default to NONE, with
NONE replaced with their real defaults of /usr/local and '${prefix}'
(respectively) later on. If we tried to expand ${prefix} at the time
that we choose the value of ${pkgconfig_prefix}, that would cause
a broken value "prefix=NONE" to be hard-coded.
[smcv: no relocation on Autotools, make it optional in CMake,
expand commit message]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721
Reviewed-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
cmake provides a macro named GnuInstallDirs to let install locations
be compatible with GNU's install location layout on several plattforms.
Using that layout makes cmake installs be more compatible to what
autotools use and also supports 32 and 64 bit installations out of the box.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Using expanded paths make no sense in install commands because they
may be patched by cmake for example by specifying DESTDIR on install.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99752
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Previously, executables like dbus-daemon were installed to
the lib subdirectory, but this was unintended. RUNTIME DESTINATION
is the equivalent of Autotools ${bindir}.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99752
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When reviewing this commit, I said
Looks OK, although this is going to become impossible if we start
using the externally-curated list of warnings from
<https://www.gnu.org/software/autoconf-archive/ax_compiler_flags.html>,
which I've been quite tempted to do.
That time has now come. I think it's more valuable to have comprehensive
warnings under our primary build system, Autotools, than to have
some fairly elaborate CMake scripting to pick up the same compiler
warnings in both build systems; the CMake build system is primarily
there to give us the ability to compile with MSVC, which has orthogonal
compiler warning options anyway.
This reverts commit 41427560af.
Signed-off-by: Simon McVittie <smcv@debian.org>
Acked-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
These source files are specific to the embedded tests and make no sense
otherwise.
Also remove a comment in the CMake build system about fixing the
build of the activation helper on Windows: the activation helper
is Unix-specific and always will be, since it relies on Unix setuid
to function.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94094
Also enable segfault checks on windows because the reason why it
has been disabled has been fixed with bug #95155.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95191
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
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>
The idea is that .travis.yml is specific to Travis-CI, but most of the
actual work is done in tools/ci-build.sh, which should be reasonably
CI-platform-agnostic (it currently assumes that build-dependendencies are
preinstalled, that the "native" platform we're building on is GNU/Linux
or something very close, and that "mingw" means mingw-w64 as packaged
in Debian and Ubuntu).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
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>
Also use SymFromAddr() instead of deprecated SymGetSymFromAddr()
as suggested on MSDN; fix some indention issues.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Previously, we didn't consistently test parsing of every file in
valid-config-files-system/ everywhere that we tested valid-config-files/.
We now test it on Unix.
The system bus is not supported on Windows, so we do not test
valid-config-files-system/ there.
valid-config-files/many-rules.conf contains <user> and <group> rules
which are not applicable to Windows. Copy the original many-rules.conf
to valid-config-files-system/ so that it will be tested on Unix, and
remove the non-portable rules from valid-config-files/many-rules.conf.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[rh:base patch came from Simon]
In particular, changing the meaning of DBUS_DATADIR part
way through the file is really confusing.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83539
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
