In a4fe15d9f0, the wayland-scanner command was changed to use
`private-code`, which was first introduced in wayland-1.14.91. This
was synced from master commit a2a99d27c9, which *did* include a
corresponding wayland version requirement bump, but it appears that
this was lost in the sync.
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
