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.
Similar to e89fcbfad6
but the tests we use mallinfo() in really aren't important to not worth
the effort to differentiate between mallinfo and mallinfo2. Only check
for mallinfo2().
GModule requires the .so file extension on macOS for historic reasons.
However Meson defaults to .dylib for modules, so we need to override
it to get the correct extension.
Fixes#3645.
When I added the sassc option, I failed to ensure that
the theme css is included in the tarballs. This is required
to make tarball builds with -Dsassc=disabled work.
Most of this is cribbed from glib.
We don't use COMMON_MESON_FLAGS here, since disabling
-Werror one subproject at a time is too painful for
all the promoted sub-sub-projects. This needs a better
solution in meson.
Since this is a full rebuild of the entire stack, limit
this to master and merge requests.
Using the module will prevent trivial bugs caused by incorrect string concatenation.
This is just a literal translation. In the future we might rely on Meson auto-detecting fields from library declaration.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3517
We released all the 3.9x development snapshots using:
libgtk-4.0.so.0.xxxx.y
which means that the 4.0.0 release of GTK will have a lower SONAME than
the snapshots. To avoid that, bump the SONAME to 1.xxxx.y.
Fixes: #3392
We don't want to increase the interface age manually, because we're
going to end up forgetting about it.
Instead, we should tie it to the rest of the version:
- in stable (even minor) cycles, we don't add new API; the interface
age is the same as the micro version
- in unstable (odd minor) cycles, every new release might have new API,
or updates to newly added API; keep the interface age to 0
This removes one more manual thing to change during release, and keeps
us honest with our promise not to add symbols during stable cycles.
