We want to use the keyfile backend in sandboxes,
but we want to avoid people losing their existing
settings that are stored in dconf. Flatpak does
a migration from dconf to keyfile, but only if
the app explictly requests it.
From an app perspective, there are two steps to
the dconf->keyfile migration:
1. Request that flatpak do the migration, by adding
the migrate-path key to the metadata
2. Stop adding the 'dconf hole' to the sandbox
To keep us from switching to the keyfile backend
prematurely, look at whether the app has stopped
requesting a 'dconf hole' in the sandbox.
The plugin modules in these tests get statically linked with a separate
copy of GLib so they end up calling vfuncs in their own copy of GLib.
Fixes#1648
GLib checks for __sync_bool_compare_and_swap, and requires
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to be defined if the function is available,
except with special cases like Linux armv5.
Extend the existing workaround to unbreak on old gcc versions that implement
__sync_bool_compare_and_swap but don't provide __GCC_HAVE_* macros.
Connect the dots between G_ADD_PRIVATE and the various G_DEFINE_* macros
that use it, as well as expanding the code example for
G_DEFINE_TYPE_EXTENDED with a private instance data declaration.
Closes: #943
We need to enable building the dirent and gnulib sources for clang-cl,
as we are still using the Microsoft-style headers and lib's and CRT.
We need to also do this for the following, for similar reasoning:
-Symbol export (via __declspec(dllexport))
-Dependency discovery without pkg-config files
-long long and ssize_t detection
We do, however, enable the autoptr tests for clang-cl builds. Note that
at this point real MSVC builds are still better supported than clang-cl
builds, and it will likely remain so for at least the near future,
alhtough real MSVC builds of the GTK stack are consumable and are usable
by clang-cl.
Use the GCC-style definition for the deprecation warning macros so that
builds using those won't break due to how they are placed as clang-cl
seems to not support __declspec(deprecated) very well. Also make sure
that we do indeed support the temparary disabling of deprecation
warnings on clang-cl, as the MSVC ones don't really work on clang-cl.
clang-cl does support __attribute__((cleanup)), which is what is used
for the g_auto* macros, but neither it, nor clang.exe defines __GNUC__
when they are used in a MSVC cmd.exe environment. It does, however,
define __clang__.
So, check for the presence of the __clang__ macro to enable g_autoptr as
well, so that we can build things with MSVC builds that make use
of g_autoptr via pretending to be MSVC by using clang-cl.
