summaryrefslogtreecommitdiff
path: root/bus/meson.build
Commit message (Collapse)AuthorAgeFilesLines
* Fix the build when dbus-broker is not foundMike Gorse2023-05-111-2/+2
|
* More build fixesMike Gorse2023-05-111-11/+32
| | | | | | | | | | | | | My last commit broke the build where dbus-daemon was set to be used by default. Added a use_systemd option that can be set to false to disable systemd. This cannot be used in combination with dbus-broker and results in dbus-broker support being disabled. If this option is left set to true, then dbus-broker support will be enabled if dbus-broker-launch is found on the system, although dbus-daemon will still be used when available unless default_bus is set to dbus-broker. Fixes #116
* Scan for dbus-daemon even if dbus-broker should be used by defaultMike Gorse2023-05-111-24/+29
| | | | | | | !134 broke the fallback to use dbus-daemon when dbus-broker was configured at build time but is not installed on the system. Fixes #115
* meson: Avoid requiring libsystemd when configured to use dbus-daemonAdrian Perez de Castro2023-04-241-27/+26
| | | | | | | | | | Checks for dbus-daemon and dbus-broker only when they are chosen with default_bus. This avoids requiring the systemd libraries if one wants the built at-spi2-core to use dbus-daemon, but dbus-worker is somehow available in the $PATH. A typical scenario is cross compilation, where the build host may have a dbus-broker program available, but the target system may not have it (or may not have nor want to use the systemd libraries).
* meson: use full_path() instead of path() for Meson 0.55 onwardsFederico Mena Quintero2022-05-231-2/+2
|
* Use abstract sockets if libdbus is older than 1.12.0Mike Gorse2021-07-061-0/+6
| | | | Fixes #37
* bus: Set X root property when Xwayland starts on-demandBenjamin Berg2021-05-191-0/+8
| | | | | | | | | | | | | | | | | | | | | On wayland, the X11 server may not always be running so that at-spi-bus-launcher cannot set it when it is starting. This is usually not a big problem, as applications can retrieve the a11y bus address by querying the session bus. Unfortunately, there may be exceptions such as applications that are run as a different user. We can easily solve this problem by setting the X11 root property when the Xwayland server is started. To do so, install a simple script to /etc/xdg/Xwayland-session.d/ that queries the session bus and sets the root property. This script is only needed when Xwayland is started on-demand, which can only happen on systemd enabled sessions. However, it is always safe to install, and there will be no severe side effects should the script be running needlessly or failing. Closes: #34
* Don't use dbus-broker if not running under systemdMichael Catanzaro2020-09-241-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since gdm@febeb9a9, gdm no longer runs a systemd user session, because gdm supports multiseat but systemd only allows one graphical session per user. Since gdm currently runs as the gdm user, that means we cannot use systemd there. Benjamin Berg says we could fix that by changing gdm to use temporary users for each seat, but that would be a lot of work. Meanwhile, dbus-broker relies on systemd to autostart D-Bus services. So if we are not running a systemd user session, nothing gets autostarted in response to D-Bus calls. That means orca never gets any response to its method calls to org.a11y.atspi.Registry, and we wind up with no accessibility on the gnome-shell login screen. Fix this by implementing Benjamin's suggested check to see if we are running under systemd before using dbus-broker. So now we will use dbus-daemon on the login screen, but we will still use dbus-broker for the user session (except in distros that still prefer dbus-daemon... which is actually the default configuration). libsystemd is added as a build dependency whenever built with dbus-broker support, which should be uncontroversial because it won't work without systemd. I expect dbus-daemon is going to live alongside dbus-broker for a long time, because it seems very hard for us to migrate fully. Big thanks to Benjamin Berg for discovering the problem and suggesting this solution. Fixes #25
* meson: Remove useless "install: true"Samuel Thibault2019-11-261-4/+0
| | | | True is already the default.
* Add /usr/lib/dbus-daemon to list of paths to check inAlan Coopersmith2019-06-161-0/+1
| | | | | | This is where Solaris installs it. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
* bus-launch: add dbus-broker supportTom Gundersen2018-05-131-7/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Both dbus-daemon and dbus-broker are now optional at compile-time, though at least one must be configured. A new configuration option is introduce in order to select the default implementation attempted at runtime. The other implementation will function as a fall-back (in case support for both are compiled in). If no default is selected, dbus-daemon remains the default as before. Unlike dbus-daemon, dbus-broker requires at-spi-bus-launch to create the listening socket and pass it in, rather than having the bus do that and send back the address. For now we follow what dbus-daemon does, and create a socket in the abstract namespace, though it might be more suitable to create a socket in $XDG_RUNTIME_DIR. The only difference users should observe is that daemons are no longer spawned by the bus implementation, but spawned and managed by the systemd user instance, though this should not lead to a difference in behavior. In particular this applies to `org.a11y.atspi.Registry`. For non-linux and non-systemd systems, dbus-daemon should continue to be used. [v2: - drop the --verbose switch, which is no longer supported - make dbus-daemon optional too - allow the default implementation to be selected] Signed-off-by: Tom Gundersen <teg@jklm.no>
* meson: x11 fixesMike Gorse2017-10-231-1/+1
| | | | | | Meson wasn't defining HAVE_X11, so x11 support wasn't being compiled even if X was determined to be present. Also, add an enable-x11 option (default is to auto-detect).
* Add Meson build systemEmmanuele Bassi2017-05-241-0/+55
Meson is a meta-build system which provides us with various advantages over Autotools: - it's portable to various platforms - it's easy to understand - it's fast - it's well maintained Various libraries in the GNOME stack have been ported to it, including GTK+ itself.