The Linux kernel hasn't used this versioning scheme for years
(the last odd-numbered development branch was 2.5).
We are still using the odd/even versioning scheme, and so are some other
library projects. Cite GLib and SDL as better examples of projects that
still use it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Now that 1.16.0 has been released and 1.15.x is EOL, it's misleading
to say that Meson is the recommended build system for Unix only on the
master branch: it's the recommended build system for Unix on the
dbus-1.16 branch, too.
This also avoids explicitly naming the master branch, which is likely
to get renamed to main.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In the longer term I'd like to move everything towards Meson so we only
have one primary build system, but at the moment Ralf would prefer to
keep recommending CMake for Windows builds (see dbus!378) so let's
stick with that for now.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The dbus maintainers can open confidential merge requests by using a
private git repository, but other contributors (including most security
researchers) cannot, so the safest simple recommendation is no merge
requests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
* Add meson build instructions and reorder the README sections
* Fix a small typo for the security section
Signed-off-by: Ahmed Abdelfattah <a.abfattah@gmail.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>
In theory the Autotools build system supports any "make" implementation,
but there are no regular contributors who test with BSD make, so the
inevitable result is that only GNU make actually works (fd.o #48277).
Apparently there's only one GNUism at the moment, which is fixable,
but that means repeating ourselves a bit more. If we instead document
that GNU make is required, we can simplify the Makefiles over time
by using extensions like $(patsubst), leading to a less error-prone
build system.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48277
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
In an embedded system where the D-Bus session is a core part of the
environment, like Maemo, accidentally auto-launching a second session bus
(for instance for a concurrent ssh session) is a bad idea - it can lead
to a "split brain" situation where half the applications in the GUI are
using a different bus. In these controlled environments, it'd be useful
to prevent autolaunch from ever happening.
(As a side benefit, the changes to configure.in also mean that packagers
can explicitly --enable-x11-autolaunch, to make sure that failure to find
X will make compilation fail cleanly.)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=19997
Bug-NB: NB#219964
* doc/dbus-specification.xml, doc/dbus-faq.xml, README: various
documentation updates. Bump faq/spec versions (not to 1.0; I don't
think the spec will be "finished"/1.0 when we ship the 1.0 library).
* dbus-pendingcall.c (_dbus_pending_call_new):
s/dbus_connection_ref/_dbus_connection_ref_unlocked fixes assertion
when we tried to take a lock on an already locked connection
* dbus-1.pc.in, dbus-glib-1.pc.in: rename these from
dbus-1.0.pc.in, dbus-glib-1.0.pc.in. As these change with the
parallel install API version, not with the D-BUS package version.
* HACKING: move some of README over here
* README: updates, and document API/ABI policy
* configure.in: reindentation
