This test assumes that pcre2 is not provided by a subproject, so force
it to be that. Explicitly allow fallback in the next check (although
it's implied already).
On some systems only `futex_time64` exists (e.g. riscv32) while on
others only `futex` exists (old Linux, 64 bit platforms), so it is
necessary to check for both and try calling both at runtime.
Additionally use the correct `struct timespec` definition. There is not
necessarily any relation between the libc's definition and the kernel's.
Specifically, the libc headers might use 64-bit `time_t` while the kernel
headers use 32-bit `__kernel_old_time_t` on certain systems.
To get around this problem we
a) check if `futex_time64` is available, which only exists on 32-bit
platforms and always uses 64-bit `time_t`.
b) otherwise (or if that returns `ENOSYS`), we call the normal `futex`
syscall with the `struct timespec` used by the kernel, which uses
`__kernel_long_t` for both its fields. We use that instead of
`__kernel_old_time_t` because it is equivalent and available in the
kernel headers for a longer time.
This will be used in upcoming commits to allow the previously-hardcoded
`/run` path to be set at configure time.
Most people will not want to change it from `/run`, even when building
test builds, as otherwise interaction with system mounts and services
will not work.
Inspired by equivalent changes in dbus.git in their commit
ff92efa389a57a5250c6996df6614234d4d462e0.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`join_paths()` automatically drops all preceding path elements if an
argument to it is an absolute path. The `/` is a tidier synonym for
`join_paths()`.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This reverts commit 91f14cd058.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This reverts commit 19353017a7.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This reverts commit 756b424cce.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
Meson now uses find_program() to get glib-mkenum from glib instead of
from system. That was already fixed at least in >=0.60 which is our
current minimum requirement.
Because Meson complains about using `configure_file(copy: true)`.
Includes improvements by Xavier Claessens.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We need to ensure that all the expected macros and utilities are working
with all the supported C standards, so just repeat the tests with all
the ones the compiler supports.
It was previously only enabled (by default) on macOS, which led to
code being committed which triggered warnings, as that CI job is not
always run.
Avoid that risk by always enabling the warning.
The reasoning for using this warning is that explicit initialisation is
clearer than implicit. We also want to support GLib’s public headers
being used in projects which build with
`-Werror=missing-field-initializers`, but can’t easily enable the
warning for our public headers but not our internal code. So enable it
everywhere.
Make it a warning rather than an error, as there’s a risk that system
header changes will trigger it in distro release builds, which would
cause false build failures. By making it a warning, GLib developers can
build with `-Werror` and promote it to an error, while distros can
choose not to.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2812
It should be enabled in all builds, not just CI builds. Otherwise
developers might miss it locally.
This updates commit f11b96f255.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Allow one to override the invalid parameter handler if we have the
following items:
* _set_invalid_parameter_hander() or
_set_thread_local_parameter_handler()
* _CrtSetReportMode() as a function or macro
Currently, we are doing this on Visual Studio to allow GSpawn to work on
Windows as well as having the log writer support color output, as we
might be passing in file descriptors that are invalid, which will cause
the CRT to abort unless the default invalid parameter handler is
overridden.
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.
C99 guarantees that va_copy() exists, so use it, instead of probing
for __va_copy(), va_copy(), or a reimplementation from first principles.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There is currently no `dllimport` attribute on any of our function,
which prevents MSVC to optimize function calls.
To fix that issue, we need to redeclare all our visibility macros for
each of our libraries, because when compiling e.g. GIO code, we need
dllimport in GLIB headers and dllexport in GIO headers. That means they
cannot use the same GLIB_AVAILABLE_* macro.
Since that's a lot of boilerplate to copy/paste after each version bump,
this MR generate all those macros using a python script.
Also simplify the meson side by using `gnu_symbol_visibility : 'hidden'`
keyword argument instead of passing the cflag manually.
This leaves only API index to add manually into glib-docs.xml when
bumping GLib version. That file cannot be generated because Meson does
not allow passing a buit file to gnome.gtkdoc()'s main_xml kwarg
unfortunately.
We require C99 now, and this warning was added for strict adherence to
C89 because GCC allowed mixed declarations in gnu89 as a GCC
extension. Let's get rid of this.
Commit 4a4d9eb662 initially switched Meson to find the python
program using find_program('python3'). Sadly that caused a
regression, since in some cases with MSVC it would fallback to
'meson.exe runpython', which is undesired.
However, that particular code was reverted back to an also
undesired lookup method, find_installation('python3'). This
way of finding python also breaks on Windows + MSVC, in particular
when setting it up as follows:
```
winget install python
winget install meson
```
This fails building GLib with:
> python3 not found
Fix that by not passing any argument to find_installation(), which
lets Meson figure it all out by itself.
The tests that functionally rely on G_ENABLE_DIAGNOSTIC=1 still set it
explicitly, so that they will behave as expected when run as
installed-tests or manually.
Signed-off-by: Simon McVittie <smcv@collabora.com>
