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.
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.
