Add meson build support
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 13:55:35 +00:00
|
|
|
/* The prefix for our gettext translation domains. */
|
|
|
|
#mesondefine GETTEXT_PACKAGE
|
|
|
|
|
|
|
|
/* Version number of package */
|
|
|
|
#mesondefine VERSION
|
|
|
|
|
2021-11-29 19:31:01 +00:00
|
|
|
/* Name of package */
|
|
|
|
#mesondefine PACKAGE_NAME
|
|
|
|
|
Add meson build support
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 13:55:35 +00:00
|
|
|
/* Version number of package */
|
|
|
|
#mesondefine PACKAGE_VERSION
|
|
|
|
|
|
|
|
/* Search path for plugins */
|
|
|
|
#mesondefine MUTTER_PLUGIN_DIR
|
|
|
|
|
|
|
|
/* */
|
|
|
|
#mesondefine MUTTER_LOCALEDIR
|
|
|
|
|
|
|
|
/* */
|
|
|
|
#mesondefine MUTTER_LIBEXECDIR
|
|
|
|
|
|
|
|
/* */
|
|
|
|
#mesondefine MUTTER_PKGDATADIR
|
|
|
|
|
|
|
|
/* Defined if EGL support is enabled */
|
|
|
|
#mesondefine HAVE_EGL
|
|
|
|
|
|
|
|
/* Defined if EGLDevice support is enabled */
|
|
|
|
#mesondefine HAVE_EGL_DEVICE
|
|
|
|
|
|
|
|
/* Defined if EGLStream support is enabled */
|
|
|
|
#mesondefine HAVE_WAYLAND_EGLSTREAM
|
|
|
|
|
|
|
|
/* Building with gudev for device type detection */
|
|
|
|
#mesondefine HAVE_LIBGUDEV
|
|
|
|
|
|
|
|
/* Building with libwacom for advanced tablet management */
|
|
|
|
#mesondefine HAVE_LIBWACOM
|
|
|
|
|
2021-08-05 14:07:28 +00:00
|
|
|
/* Building with libsystemd */
|
|
|
|
#mesondefine HAVE_LIBSYSTEMD
|
|
|
|
|
Add meson build support
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 13:55:35 +00:00
|
|
|
/* Define if you want to enable the native (KMS) backend based on systemd */
|
|
|
|
#mesondefine HAVE_NATIVE_BACKEND
|
|
|
|
|
|
|
|
/* Define if you want to enable Wayland support */
|
|
|
|
#mesondefine HAVE_WAYLAND
|
|
|
|
|
2022-05-06 13:51:40 +00:00
|
|
|
/* Define if you want to enable XWayland support */
|
|
|
|
#mesondefine HAVE_XWAYLAND
|
|
|
|
|
|
|
|
/* Define if you want to enable X11 backend support */
|
|
|
|
#mesondefine HAVE_X11
|
|
|
|
|
|
|
|
/* Define if either XWayland or X11 backend are enabled */
|
|
|
|
#mesondefine HAVE_X11_CLIENT
|
|
|
|
|
Add meson build support
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 13:55:35 +00:00
|
|
|
/* Defined if screen cast and remote desktop support is enabled */
|
|
|
|
#mesondefine HAVE_REMOTE_DESKTOP
|
|
|
|
|
2022-03-03 10:51:00 +00:00
|
|
|
/* Defined if gnome-desktop is enabled */
|
|
|
|
#mesondefine HAVE_GNOME_DESKTOP
|
|
|
|
|
2022-04-26 13:00:46 +00:00
|
|
|
/* Defined if sound player is enabled */
|
|
|
|
#mesondefine HAVE_SOUND_PLAYER
|
|
|
|
|
Add meson build support
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 13:55:35 +00:00
|
|
|
/* Building with SM support */
|
|
|
|
#mesondefine HAVE_SM
|
|
|
|
|
|
|
|
/* Building with startup notification support */
|
|
|
|
#mesondefine HAVE_STARTUP_NOTIFICATION
|
|
|
|
|
2020-08-26 09:49:50 +00:00
|
|
|
/* Building with Sysprof profiling support */
|
2019-05-31 15:42:27 +00:00
|
|
|
#mesondefine HAVE_PROFILER
|
2018-05-15 15:31:29 +00:00
|
|
|
|
Add meson build support
This commit adds meson build support to mutter. It takes a step away
from the three separate code bases with three different autotools setups
into a single meson build system. There are still places that can be
unified better, for example by removing various "config.h" style files
from cogl and clutter, centralizing debug C flags and other configurable
macros, and similar artifacts that are there only because they were once
separate code bases.
There are some differences between the autotools setup and the new
meson. Here are a few:
The meson setup doesn't generate wrapper scripts for various cogl and
clutter test cases. What these tests did was more or less generate a
tiny script that called an executable with a test name as the argument.
To run particular tests, just run the test executable with the name of
the test as the argument.
The meson setup doesn't install test files anymore. The autotools test
suite was designed towards working with installed tests, but it didn't
really still, and now with meson, it doesn't install anything at all,
but instead makes sure that everything runs with the uninstalled input
files, binaries and libraries when running the test suite. Installable
tests may come later.
Tests from cogl, clutter and mutter are run on 'meson test'. In
autotools, only cogl and clutter tests were run on 'make check'.
2018-05-22 13:55:35 +00:00
|
|
|
/* Path to Xwayland executable */
|
|
|
|
#mesondefine XWAYLAND_PATH
|
|
|
|
|
|
|
|
/* Xwayland applications allowed to issue keyboard grabs */
|
|
|
|
#mesondefine XWAYLAND_GRAB_DEFAULT_ACCESS_RULES
|
|
|
|
|
|
|
|
/* XKB base prefix */
|
|
|
|
#mesondefine XKB_BASE
|
|
|
|
|
2019-09-27 08:15:48 +00:00
|
|
|
/* Whether <sys/prctl.h> exists and it defines prctl() */
|
|
|
|
#mesondefine HAVE_SYS_PRCTL
|
|
|
|
|
2019-06-20 10:11:29 +00:00
|
|
|
/* Either <sys/random.h> or <linux/random.h> */
|
|
|
|
#mesondefine HAVE_SYS_RANDOM
|
|
|
|
#mesondefine HAVE_LINUX_RANDOM
|
2019-07-19 20:50:31 +00:00
|
|
|
|
|
|
|
/* Whether Xwayland has -initfd option */
|
|
|
|
#mesondefine HAVE_XWAYLAND_INITFD
|
2020-01-17 22:43:24 +00:00
|
|
|
|
2021-01-22 10:16:24 +00:00
|
|
|
/* Whether Xwayland has -listenfd option */
|
|
|
|
#mesondefine HAVE_XWAYLAND_LISTENFD
|
|
|
|
|
2020-01-17 22:43:24 +00:00
|
|
|
/* Whether the mkostemp function exists */
|
|
|
|
#mesondefine HAVE_MKOSTEMP
|
|
|
|
|
|
|
|
/* Whether the posix_fallocate function exists */
|
|
|
|
#mesondefine HAVE_POSIX_FALLOCATE
|
|
|
|
|
|
|
|
/* Whether the memfd_create function exists */
|
|
|
|
#mesondefine HAVE_MEMFD_CREATE
|
xwayland: Check X11 clients prior to terminate Xwayland
Currently, mutter checks for the presence of X11 windows to decide
whether or not Xwayland can be terminated, when Xwayland is started on
demand.
Unfortunately, not all X11 clients will map a window all the time, an
X11 client may keep the X11 connection opened after closing all its
windows. In that case, we may terminate Xwayland while there are some
X11 client connected still, and terminating Xwayland will also kill
those X11 clients.
To avoid that issue, check the X11 clients actually connected using the
XRes extension. The XRes extension provides the PID of the (local) X11
clients connected to the Xserver, so we need to match that against the
actual executable names, and compare with a list of known executables
that we can safely ignore, such as ibus-x11 or gsd-xsettings.
We also check against our own executable name, considering that the X11
window manager is also an X11 client connected to the Xserver.
Also, XRes returning the PID of local clients only is not a problem
considering that Xwayland does not listen to remote connections.
However, if the user spawns a client remotely on another system using
ssh tunneling (ssh -X), only clients which actually map a window will
be accounted for.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1537
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1671>
2021-01-18 09:22:01 +00:00
|
|
|
|
xwayland: Mark our X11 connection terminatable
The connection to the Xserver for the X11 window manager part of mutter
even on Wayland may prevent the Xserver from shutting down.
Currently, what mutter does is to check the X11 clients still connected
to Xwayland using the XRes extension, with a list of X11 clients that
can be safely ignored (typically the GNOME XSettings daemon, the IBus
daemon, pulseaudio and even mutter window manager itself).
When there is just those known clients remaining, mutter would kill
Xwayland automatically.
But that's racy, because between the time mutter checks with Xwayland
the remaining clients and the time it actually kills the process, a new
X11 client might have come along and won't be able to connect to
Xwayland that mutter is just about to kill.
Because of that, the feature “autoclose-xwayland” is marked as an
experimental feature in mutter and not enabled by default.
Thankfully, the Xserver has all it takes to manage that already, and
is even capable of terminating itself once all X11 clients are gone (the
-terminate option on the command line).
With XFixes version 6, the X11 clients can declare themselves
"terminatable", so that the Xserver could simply ignore those X11
clients when checking the remaining clients and terminate itself
automatically.
Use that mechanism to declare mutter's own connection to the Xserver as
"terminatable" when Xwayland is started on demand so that it won't hold
Xwayland alive for the sole purpose of mutter itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
2021-03-17 14:44:45 +00:00
|
|
|
/* Whether the Xwayland -terminate supports a delay */
|
|
|
|
#mesondefine HAVE_XWAYLAND_TERMINATE_DELAY
|
2023-01-09 14:40:03 +00:00
|
|
|
|
|
|
|
/* Whether the Xwayland supports +/-byteswappedclients */
|
|
|
|
#mesondefine HAVE_XWAYLAND_BYTE_SWAPPED_CLIENTS
|
2023-03-07 05:21:19 +00:00
|
|
|
|
|
|
|
/* Defined if libdisplay-info is enabled */
|
|
|
|
#mesondefine HAVE_LIBDISPLAY_INFO
|
2023-09-29 09:00:37 +00:00
|
|
|
|
|
|
|
/* Whether the Xwayland has -enable-ei-portal option */
|
|
|
|
#mesondefine HAVE_XWAYLAND_ENABLE_EI_PORTAL
|