Subprojects that use meson.override_dependency() do not require the
caller to provide the dependency variable name inside the subproject.
We also don't want to provide the *subproject* name, because the
subproject name can be `pango-1.50.12` instead of `pango` when using
wrap-file to download the tarball instead of using wrap-git. This
causes the pango subproject to be executed twice when using gtk as
a subproject inside gstreamer (which uses pango-1.50.12 as
a wrap-file).
All the dependencies we use can be switched in this way, but the
remaining ones need to be changed to use meson.override_dependency()
first.
The is_msvc_like change is wrong; it used a false correlation between
"compiler being used" and "dependency method" by saying that on
Windows, when building with MSVC, you will only use CMake to find png,
jpeg, tiff.
You can use pkgconfig to find these deps on Windows with MSVC -- when
the deps have been built with Autotools or Meson (with MSVC). You can
also find these deps using CMake on other platforms like macOS or
Linux.
The solution is simple: just search for both names on all platforms,
and just search for the pkgconfig name first.
This reverts commit acd9c12667.
This commit breaks the build with GLib main on all platforms,
and defining _GLIB_EXTERN arguably invades the GLib namespace.
A different fix for msvc will have to be found.
This is an experiment to see if I can keep up with
doing post-release version bumps, so git snapshots
will always have a different version from released
tarballs.
This commit also marks the beginning of the 4.10
development cycle, as 4.8 has been branched.
gi-docgen is supposed to be ran natively on the build machine, without
native: true dependency() searches for gi-docgen on the host system.
When it doesn't find it, it falls back to a subproject even if gi-docgen
is available on the build machine.
also make gtk_doc require introspection
Sysprof has a new -Dagent=true build option which allows installing a
/usr/bin/sysprof-agent program (simimlar to sysprof-cli). It provides a
P2P D-Bus API to the process which can control subprocesses. It's used by
IDE tooling to have more control across container boundaries.
However, we do not need it for GTK CI.
The GdkToplevelSize struct already has the concept of "bounds", which
means the largest size a window should reasonably have. It's practically
the equivalent of the monitor the window is intended to be mapped on,
with the "struts" (e.g. panels) cut out. It's used by GTK to use this
information to calculate a default window size that is "lagom" (swedish;
not too large, not too small).
Meson knows all private dependencies itself when passing the library as
first positional argument, no need to specify them manually. Also
simplify backend specific files by simply requiring gtk4, just like
unix-print already did.
This should fix generated gtk4-uninstalled.pc, see Meson bug report:
https://github.com/mesonbuild/meson/issues/10415
Ensure that resolution of the subproject occurs via the dependency
interface, not the "poke at subprojects manually" interface, and make
that actually work via --wrap-mode=forcefallback.
There's no need to mark it as not-required and then manually invoke
subproject(), since fallback should work correctly and it is always
needed.
However, if fallback was performed (or forced) it would error out since
get_variable() was instructed to only use pkg-config while the relevant
variable was exported by the subproject as an internal fallback
dependency.
One may be using IJG libjpeg or libjpeg-turbo to build GTK, and their
build files may or may not generate pkg-config files for us. To make
things easier, we can make use of CMake's built-in support for finding
IJG libjpeg or libjpeg-turbo.
The CMake build files for libtiff may or may not generate pkg-config
files for us, so we can use Meson's CMake support to help us find
libtiff, as CMake has built-in support for finding libtiff.
Add a variable in meson.build that covers Visual Studio-like compilers,
so that we can use it to help us find depedencies using CMake rather
than via pkg-config, where applicable.
Change the existing use case for finding libpng accordingly.
From the GCC manpage:
> Wimplicit-fallthrough=5 doesn't recognize any comments as
> fallthrough comments, only attributes disable
> the warning.
So, check for the =5 version after checking for the simple version. This
way we get -Wfallhrough with clang and -Wfallthrough -Wfallthrough=5
with GCC, which works.
This makes the hotspot of DND surfaces work when using the Vulkan and
OpenGL renderers.
This bumps the CI image used to the newly built image. This is needed to
install a new enough libwayland-client.so needed for wl_surface.offset.
This is done by adding wayland as a meson subproject, building it
on-demand if the version in the system is not new enough. As
libwayland-client.so is pulled in implicitly when linking to gtk4, the
compile step needs LD_LIBRARY_PATH set to make ld find the right library
to link to.
Without building the demos, nothing gets installed into $prefix/share/icons/hicolor. Which makes running
`gtk4-update-icon-cache` on the machine causes an error. This is easily reproducible on a Windows machine with MSVC where
there is nothing pre-installed on hicolor icon theme and that makes building gtk without the demos fails with "No such file or directory".
I forgot to remove the '-Werror=' part from all the extra warnings, so
the warning/error flags we generated were '-Werror=-Werror=warning-flag'
or 'W-Werror=warning-flag' - but because our compiler flag checking
infrastructure works so nicely, it just ignored these obviously wrong
flags.
Fixes commit 362e91c40b
Do kep them for debug and debugoptimized builds though.
Keeping -Werror flags in release builds causes issues with forward
compatibility, when new compiler releases or different toolchains
suddenly cause those warnings to be emitted during compilation.
While we certainly want those issues to be investigated and fixed, they
should not prevent anyone from building GTK until they are.
Resolves#4388
On Visual Studio-style builds, it is likely that we do not have pkg-config
files for libpng, so improve the search for libpng by using CMake's built-in
mechanisms for looking for libpng. This, however, means that we need to use
'png' rather than 'libpng' for the package name to search for.
Add support for the tiff format, which is flexible
enough to handle all our memory texture formats
without loss.
As a consequence, we are now linking against libtiff.
Using libpng instead of the lowest-common-denominator
gdk-pixbuf loader. This will allow us to load >8bit data,
and apply gamma and color correction in the future.
For now, this still just provides RGBA8 data.
As a consequence, we are now linking against libpng.
Basically, I was building some packages on Guix. I figured out that
wayland-protocols was listed among propagated-inputs for gtk+ package
(gtk-3-24). propagated-inputs holds a list of runtime dependencies,
that should be available to any other package that depends on gtk+.
While discussing we clarified that wayland-protocols is not runtime
dependency. So I moved it to native-inputs of gtk+ package, which
means that, this dependency will be available only to gtk+ package and
only at build time. Once moved, building of other applications that
depening on gtk+ started to fail.
Investigation showed that, all .pc (pkg-config) files prepared by gtk+
package, was including:
Requires.private: ... wayland-protocols ...
Since it becomes requirement, other applications was failing with
missing dependency wayland-protocols of dependency gtk+, for instance:
-- Checking for module 'gtk+-3.0'
-- Package 'wayland-protocols', required by 'gdk-3.0', not found
While actually wayland-protocols is not even a build time dependency
of application that depends on gtk+. Advertisement of such
requirement, is a bit misleading, because one does not need it at
runtime, especially applications based on gtk.
That's a sneaky trick so my edit/compile/test cycle goes faster:
I usually use demos for testing so the tools don't have to be linked for
me to start testing.
It's only used during DND to allow use of the root window's cow window
as a DND target, because apparently gnome-shell used to think that was a
great idea to DND to the overview.
Somebody complain to gnome-shell devs about it not being a good idea if
they want it fixed.
Potentially using Wayland is a better idea though.
This reverts 85ae875dcb
Related: https://bugzilla.gnome.org/show_bug.cgi?id=601731
It's not 2011 anymore, and we shouldn't randomly build one of 10.000
different combinations of X11 backends (I counted the possibilities) but
exactly the one we expect people to use.
Instead, ensure that sassc is made madatory on git builds (because
it is, we don't ship CSS files anymore) and not even looked for in
release builds (because do ship CSS files there).
We hardcoded the typelib directory for only an arch (and a distro),
while we can just get it from gobject-introspection pkg config if tests
are enabled.
We can't use this flag for any code that may get run
outside the __builtin_cpu_supports() check, and meson
doesn't allow per-file cflags. So we have to split this
code off into its own static library.
When building for homebrew/linuxbrew on Ubuntu 16.04, memfd_create() is
not available and causes the build to fail.
This adds a proper check for the function.
The gtk_debug_cflags variable is an array, with each argument stored in
a separate string; if we add multiple arguments inside the same string
we break the escaping rules.
Fixes: #3864
It is also possible to enable F16C instructions on 32-bit Visual Studio builds,
so also check for the compiler's ability to build F16C code on Visual Studio
32-bit instead of just bailing out.
The __builtin_cpu...() intrisics are strictly for GCC/CLang-based compilers, so
don't use them in the checking code on Visual Studio. The test code will still
compile without this change, but will certainly fail if we want it to link.
Use an IFUNC resolver to determine whether we can use
intrinsics for FP16 conversion. This requires the functions
to be no longer inline.
Sadly, it turns out that __builtin_cpu_supports ("f16c")
doesn't compile on the systems where we want it to prevent
us from getting a SIGILL at runtime.
Stop using gtk-doc, and switch to gi-docgen.
The gi-docgen tool generates API references through the introspection
data, which has various benefits:
- it does not parse C code
- it does not generate and run C code to introspect types at build time
- it does not present a different API from the one we're exporting
Additionally, gi-docgen:
- does not generate DocBook XML in order to generate HTML
- does not go through xsltproc
- parses proper Markdown
Which makes it markedly faster than gtk-doc has ever been.
