The default `when: on_success` means no artifacts are exported when the
tests fail, which is precisely when we want to see the artifacts.
Always export them, and rely on GitLab to garbage collect them as
appropriate (typically after 30 days, I think).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This means that compilation and test failures will leave logs on the CI
machines which we can use to debug the failures.
Always export the artifacts. The default `when: on_success` is
appropriate for now, but won’t be in future when the tests actual report
their success value correctly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add a test macro that allows comparing two floating point values for
equality within a certain tolerance.
This macro has been independently reimplemented by various projects:
* Clutter
* Graphene
* colord
https://gitlab.gnome.org/GNOME/glib/issues/914
It's a synonym of G_VOLUME_IDENTIFIER_KIND_UNIX_DEVICE.
It doesn't change anything except not feeling dirty from using a wrongly
prefixed constant for the object type.
See: #182
valgrind.h is a verbatim copy taken from Valgrind project. Previously
that file had local changes that got dropped by last update. To avoid
regressing again, do not edit valgrind.h anymore and instead add a
gvalgrind.h wrapper that gets included instead.
This fix 2 errors:
- uintptr_t is not defined when including valgrind.h on mingw.
- MSVC compiler is not supported on amd64-Win64 platform.
Better not modify copy/paster files otherwise this will regress again
later. It's better to not include valgrind.h at all when using MSVC.
This reverts commit bbcce75d4e.
This adds to the CI a cross build for Android NDK r16 API 21 (because
thats what GStreamer currently use) for arm64.
GNU iconv must be built manually into our docker image because Android
NDK doesn't seems to ship it. The latest NDK r17 API 28 has iconv.h but
iconv_open() symbol isn't found by the linker. Looks like broken NDK.
libffi also needs to be built manually because the meson subproject
doesn't support building for Android platform. It needs a recent RC
release because latest stable release is 4 years old and fails to
build.
Fixes#1385.
Help is usually printed from tools if no arguments are given and there
is not default action. However "gio mount" and "gio trash" just silently
return. Let's print "No locations given" error and show help consistently.
"gio help COMMAND" shows some arguments with "..." and some with "…",
which looks weird, e.g.:
$ gio help mount
gio mount [OPTION…] [LOCATION...]
Let's use "…" consitently.
gcc defaults to utf-8 for both (see -fexec-charset and -finput-charset in the
gcc man page) so we should use it with msvc as well.
msvc by default uses the locale encoding unless there is a BOM, see
https://msdn.microsoft.com/en-us/library/mt708821.aspx
The tests in test_async_queue_timed() assume that g_async_queue_timeout_pop()
and in turn g_cond_wait_until() wait at least until end_time
before returning, i.e. calling g_get_monotonic_time() after the timeout should result
in a value equal or larger than the timeout end time.
For the win32 implementation of g_cond_wait_until() this isn't the case which
makes those tests fail.
There are three reasons why the function returns early:
1) The underlying API works with milliseconds and the timeout gets rounded
down, resulting in a too small timeout value.
2) In case the timeout is too large to be passed to the API it gets limited
(there is also a bug because it converts INFINITE to milliseconds while
they already are, but using INFINITE would be wrong as well, as passing
a large timeout is not the same as blocking forever really)
3) Even with the rounding changed the underlying API still returns a bit early
sometimes on my machine (relative to g_get_monotonic_time())
This changes the implementation to round up to the next millisecond (fixing 1)
and to wait again in case a timeout occurs but the end time hasn't been
reached yet (fixing 2 and 3).
This makes the test_async_queue_timed() tests pass.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
The timer tests expect that a small value for sleep does not result in
no sleep at all. Round up to the next millisecond to bring it more in line
with other platforms.
This fixes the glib/timer tests.
This makes the 'threadtests' time out since that uses small usleeps a lot and
until now didn't wait at all, but now always waits a msec. Reduce the amount
of tests done on Windows to get the runtime down to something reasonable again.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
