We forgot to account for the case where we lookup for HarfBuzz manually
under Visual Studio builds, so only set HAVE_HARFBUZZ (and thus
HAVE_PANGOFT, since PangoFT2 depends on HarfBuzz) after we did the
fallback check for HarfBuzz.
Also, check for hb.h instead of harfbuzz/hb.h to be inline with the
pkg-config case, as the sources also include the HarfBuzz header by
using #include <hb.h>, not #include <harfbuzz/hb.h>
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Check for freetype2 version, because pangoft works with any version
(pangoft availability does not indicate that ft2 is new enough), unlike
GTK.
On Windows, since pangoft is optional, we check for the presence of
freetype2 .pc file first after finding that we have pangoft, and then
check for FT_Get_Var_Design_Coordinates() manually by looking for the
freetype headers and .lib first, and then looking for the presence of
that symbol, since freetype2's Visual Studio build system does not
generate a .pc file for us.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Meson warns when doing that, as it's not really portable.
Since we're using platform-specific linker flags on Darwin, we can also
do the same on Linux; the syntax is GCC-specific, so we're going to need
Clang users to test it.
This way, we can support external libraries providing implementations of
GtkMediaFile.
We also add a media backend called 'nomedia' that can be enabled to not
compile any support for GtkMediaFile. This is useful when people want to
statically compile GTK into an application that does not use media.
For now, this option is the default.
We also support a new environment variable GTK_MEDIA that allows
selecting the implementation to use.
GTK_MEDIA=help can be used to get info about the available
implementations.
This makes demos be compiled/linked before tests. And that means that
while hacking, I can already run widget-factory when the tests are
still linking.
Release builds should only disable cast checks, to match what we used
to do back with the Autotools builds.
The Autotools build had an "--enable-debug=no" option, but that was
rarely used; Meson has debug, debugoptimized, release, and plain build
types, but we considered the "release" build types as the old "disable
all debugging code", which is not really accurate.
Disabling assertions and preconditon checks should be left to people
with constrained environments and/or packagers; they are supposed to
use the "plain" build type, and override the CFLAGS themselves.
Drop the 'enable-' prefix, and always enable all platform-specific
backends. We can disable them depending on the platform. This way,
the documentation printed by `meson configure` remains accurate.
Instead of having separate options for each print backend, we can use
the same approach as the input method modules: a single option, with a
comma-separated list of print backends.
The standard Vulkan SDK ships with a pkg-config file, like a modern
library should.
We should fall back to finding the library and header only for platforms
where pkg-config is not really a thing.
Based on a patch by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793181
Add the necessary machinery into the Meson definition files so that we
can build for Windows.
Since we don't have Wayland or X support for our use case here, disable
them once we know that we are building for Windows, as they are
(otherwise) enabled by default, and enable the items that need to be
built for Windows builds.
Exclude gtk4-launch from Windows builds as that is something that
is not supported on Windows.
As we won't have gio-unix on Windows, and PangoFT2 is optional, don't use
fallbacks for them when we are on Windows (but do use fallbacks for
gio-win32, as it will be used).
Also, clean up meson.build a bit as we can just force-include
msvc_recommended_pragmas.h from GLib since we depend on GLib, and so we
can handle these warnings from msvc_recommended_pragmas.h instead.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
-Wshadow these days does not overwarn anymore like it did in gcc 4.
There are no warnings inside gtk, so better enable it to keep it that
way.
-Wuninitialized also has no positives, so I'm gonna turn it on just
because.
-Wint-conversion is important because it checks casts from ints to
pointers.
-Wdiscarded-qualifiers is important to catch cases where we don't
strings when we should.
Otherwise it fails to build with:
FAILED: gtk/im-ipa@sha/imipa.c.o
...
In file included from ../gtk/gtkintl.h:4:0,
from ../modules/input/imipa.c:28:
/opt/include/glib-2.0/glib/gi18n-lib.h:27:2: error: #error You must
define GETTEXT_PACKAGE before including gi18n-lib.h. Did you
forget to include config.h?
#error You must define GETTEXT_PACKAGE before
including gi18n-lib.h. Did you forget to include config.h?
^~~~~
../modules/input/imipa.c:144:3: error: ‘GETTEXT_PACKAGE’ undeclared
here (not in a function)
GETTEXT_PACKAGE, /* Translation domain */
^~~~~~~~~~~~~~~
../modules/input/imipa.c:145:4: error: ‘GTK_LOCALEDIR’ undeclared
here (not in a function)
GTK_LOCALEDIR, /* Dir for bindtextdomain (not strictly
needed for "gtk+") */
^~~~~~~~~~~~~
For dependencies that do not generate pkg-config files for their Visual
Studio build systems, we need to look for them using cc.has_header() and
cc.find_library(), namely for Cairo and HarfBuzz, if one does not have
crafted pkg-config files for them (which, by themselves may be
error-prone).
As a result, we will still try to look for Cairo and HarfBuzz using
pkg-config, but will give another shot at them on Visual Studio using
cc.has_header() and cc.find_library() if they couldn't be found via
pkg-config.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
The Vulkan .lib file that is supplied by the LunarG Vulkan SDK is
vulkan-1.lib, not vulkan.lib, so make sure we look for the right
libraries when building on Visual Studio (I am not sure whether the
LunarG SDK will work for MinGW/mingw-w64 builds, as only Visual Studio
.lib files are provided).
Note that this will require one to set LIB and INCLUDE appropriately to
find the Vulkan .lib and header files, and possibly PATH if one's video
drivers do not contain the Vulkan runtime DLL.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
This is meant to cut down build time in flatpak and similar
situations. Since it produces technically incomplete builds,
we list these options in the status output at the end of
the meson run.
Add integration of the libcloudproviders DBus API to the
GtkPlacesSidebar by showing name and sync status of the cloud providers.
The exported menu is rendered as a GtkPopover.
The sidebar will be updated if the list of cloudproviders changes e.g.
by adding or removing an account. If any cloud provider changes detailed
information like sync status only the individual sidebar row gets
updated.
Co-authored-by: Carlos Soriano <csoriano@gnome.org>
Co-authored-by: Daniel Boles <dboles@src.gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=786123
We cargo-culted this from Autotools, but GCC on Windows supports the
same __declspec syntax as MSVC. The only difference is the additional
flag needed for GCC-like compilers.
The linker on macOS does not support '=' in its command line; there's no
guarantee that we are using the correct compatibility versions compared
to the Autotools build, but for that we'll need to build GTK+ master on
macOS.
We're mixing a lot of styles in the Meson build files. This is an
attempt at making everything slightly more consistent in terms of
whitespace and indentation.
When building GTK+ straight from the repository without any assistance
from packaging tools, we need to trigger system-wide updates, like the
icon theme cache update, or the schema compilation.
We need to check if the linker flags we use are available, depending on
the platform, and we need to ensure that the shared library is
versioned appropriately.
GTK symbols are not visible by default, and only the ones annotated with
_GDK_EXTERN (and wrapper macros) are exported. We need to define
_GDK_EXTERN during the configuration, depending on the platform and
compiler we use.
The autotools build checks the version of GLib we are depending on in
order to generate the appropriate GLIB_VERSION values for the
min-required/max-allowed defines.
We have to work around some ordering problems here. We still
manage to keep most of the guts in modules/input/meson.build,
so it's not too ugly overall.
(The autotools build solves this with a 'make -C ../../input/modules'
inside gtk/Makefile, but that's not something we can or want to do.)
Remove workaround for gcc bug (Meson does that now), and
construct the right config.h defines for the headers on
the fly instead of listing them in the build file, which
is more error prone.
