The `name` and `description` events were added to `xdg-output` protocol
in version 2 which is part of wayland-protocols 1.14.
In xdg-output-v1 version 3, the `xdg-output.done` event was deprecated
and the `xdg-output.description` event was made mutable, but that
doesn't change the actual events so we do not actually need to require
that version of xdg-output from wayland-protocols 1.18.
Update the wayland-protocols requirement to the bare minimum version,
which is 1.14.
https://gitlab.gnome.org/GNOME/gtk/issues/2057
This commit fixes the values passed to darwin_versions. When
transitioning from an autotools build, one should always use:
[lt_current + 1, '@0@.@1@.0'.format(lt_current + 1, lt_revision)]
This is a backport of the GdkProfiler from master. It does not include
the pixel bandwidth numbers that come from gdkdrawcontext.c since there
does not seem to be an analog in 3.x.
Additionally, this implements the recent changes for SYsprof's D-Bus
profiler API which adds a Capabilities property and an options hash-table
to the D-Bus interface for forward portability.
Commits a04fef4 and cc7f9c4 inadvertedly broke Visual Studio builds as
it caused the following to show up when configuring:
gdk\meson.build:281:0: ERROR: Invalid Shared library version "vs9.2404.4". Must be of the form X.Y.Z where all three are numbers. Y and Z are optional.
Since we do not set a library version that mingles with the minor and
micro versions, along with libtool current for any Visual Studio builds,
just set those versions as 3 on Visual Studio builds, and things should
work the way they did before.
Make it a yes/no/auto combo. "yes" means all modules are built into libgtk,
"no" that none are and "auto" uses the platform defaults, yes on win32,
no otherwise.
If we need more we can always extend it later.
This makes the DLL names match those that are produced by the Visual
Studio projects by default.
This, currently, however, names the .lib files same as the ones that
are produced for other platforms (i.e. <libname>-3.lib). This is
actually not that bad as one can just copy those .lib's into
<libname>-3.0.lib when needed and the binaries that link to those .lib's
ultimately link to the same DLLs, so this should not harm binary
compatibility.
It may be so that Cairo is not found using pkg-config files, so we
cannot just use .name() on the Cairo deps directly.
Since we already have a similar mechanism for generating the GDK .pc
files, re-use and share that mechanism.
It seems that Meson 0.50.0 broke dependency search using CMake for
HarfBuzz at least, so we add a workaround for it to look for the
HarfBuzz headers and libraries manually when we couldn't find HarfBuzz
using the pkg-config and CMake method.
Various adjustments to make the config.h output between autotools
and meson more similar by testing on Linux and Windows/MSYS2.
Setting things to 1 instead of true and shifting things around is motivated
by reducing the diff between the generated files.
Try to include the same things and in a similar order so differences
are easier to catch.
This also adds the backend specific .pc files for gdk like gdk-x11-3.0.pc
Build the input modules for GTK+, either as modules or built directly
into GTK. Also provide a configure option to build the specified
immodules, or all, or the backend immodule(s) or none of the immodules
into GTK. Note that for Visual Studio all immodules are built into
the GTK DLL by default, like what is done in the Visual Studio projects.
Note that building the backend immodules for Quartz, X11 and Wayland are
currently untested.
This is so that the post install script will work on environments where
*NIX shell scripts are not supported, such as on Windows cmd.exe for
Visual Studio builds.
PangoFT2 is optional on Windows, so we only really need the fallback if
when it is required.
Along with that, since FreeType does not typically ship with pkg-config
files in its CMake builds, check for the needed headers, .lib and
function and then use the fallback when they could not be found and
PangoFT2 is used.
On Visual Studio builds, since Cairo builds tend not to generate
pkg-config files for us, look for the headers and .lib's, before
attempting to download the Cairo repo (which is quite large) and
building it.
We can simplify this process when Meson gains the ability to check
for the dependencies in a declarative fashion, but before that, this
is what must be done.
