We need to make sure that such binaries are built and available at test time
or we may fail some tests requiring them (directly or through desktop file).
As per this, and because now generated desktop files are available both
at build and install time, don't skip some tests we were used to, but
actually enforce they are running.
We have some test programs on which some tests depend on, for example
appinfo-test is a tool that is used by the desktop-app-info tests.
So test can now have an 'extra_programs' key where the extra program
names can be included.
This could have been handled manually via 'depends', but this allows
to avoid repeating code and be sure that all is defined when extra
programs targets are checked.
We were generating .desktop files with different content when installed
tests were enabled, and thus making impossible to test some cases
because there was no built file until installed.
To avoid this, always generate both versions of desktop files while
install only the one containing the install path prefix if needed.
Given that it can be computed using an error-prone strings comparisons it
is better to provide a variable everywhere, so that we don't have the
risk of comparing values that are always false.
We have tests that are failing in some environments, but it's
difficult to handle them because:
- for some environments we just allow all the tests to fail: DANGEROUS
- when we don't allow failures we have flacky tests: A CI pain
So, to avoid this and ensure that:
- New failing tests are tracked in all platforms
- gitlab integration on tests reports is working
- coverage is reported also for failing tests
Add support for `can_fail` keyword on tests that would mark the test as
part of the `failing` test suite.
Not adding the suite directly when defining the tests as this is
definitely simpler and allows to define conditions more clearly (see next
commits).
Now, add a default test setup that does not run the failing and flaky tests
by default (not to bother distributors with testing well-known issues) and
eventually run all the tests in CI:
- Non-flaky tests cannot fail in all platforms
- Failing and Flaky tests can fail
In both cases we save the test reports so that gitlab integration is
preserved.
We have gnulib warnings in windows under clang:
../glib/gnulib/vasnprintf.c:2429:21: warning: variable 'flags' set but not
used [-Wunused-but-set-variable]
int flags = dp->flags;
^
../glib/gnulib/vasnprintf.c:4853:19: warning: unannotated fall-through
between switch labels [-Wimplicit-fallthrough]
case TYPE_LONGINT:
^
See: https://gitlab.gnome.org/3v1n0/glib/-/jobs/2361750
C99 does not actually guarantee that the platform has 8-, 16-, 32- and
64-bit types, but it does guarantee that if the platform has them, then
(u)intN_t are defined to be examples of those types.
GLib goes beyond what C99 guarantees, and requires 8-, 16-, 32- and
64-bit types; combining that with C99's requirements means we can
assume that int8_t, uint64_t, etc. all exist.
Unfortunately, we cannot guarantee that GLib and the C99 toolchain have
chosen the *same* fixed-size type: for example, on a typical ILP32
or LLP64 platform like Windows or 32-bit Linux, each 32-bit type could
either be int or long, while on a LP64 platform like 64-bit Linux,
each 64-bit type could either be long or long long. The in-memory
representation is the same either way, but the choice of underlying type
matters when building printf format strings or issuing compiler warnings.
As a result, we can't just typedef gint32 as int32_t and so on.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
The important thing here is that we can't arbitrarily mix these, even if
they will often have the same in-memory representation.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
These have a status similar to size_t: they're Standard C types and
straightforward to use in portable code this decade, but we can't
guarantee that we have chosen the same underlying type that the platform
uses.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is similar to the relationship between gsize and size_t, except
that size_t is a Standard C type but ssize_t is platform-specific
(specifically, ssize_t is a POSIX type, and on Windows the equivalent
is SSIZE_T), making it more awkward to use in portable code. As a
result, continuing to use gssize is more useful than continuing to use
gsize.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
We have chosen the underlying type that implements gsize to be the same
size as the standard C89 size_t (the top-level meson.build sets this up).
Unfortunately, we cannot guarantee that GLib and the C toolchain have
chosen the *same* fixed-size type: for example, on a typical ILP32
platform like 32-bit Windows or Linux, each of gsize and size_t
can either be int or long, while on a LP64 platform like 64-bit Linux,
each could either be long or long long. meson.build tries to choose the
same type to reduce compiler warnings, but it can only do this if the
compiler implements `-Werror`.
The in-memory representation is the same either way, but the choice of
underlying type matters when building printf format strings or issuing
compiler warnings, and can affect the C++ ABI of GLib-based software.
As a result, we can't just typedef gsize as size_t.
I've expanded the doc-comment to say a bit more about the implications
of the different types here, so that I can point to it from the
doc-comments of other types without repeating myself too much.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
