This is a departure from our policy of using the minimum required Meson
version, but I think it might be worth a try to see if it fixes the
persistent intermittent build failures on these platforms due to what
looks like build dependency graph issues.
For example:
- https://gitlab.gnome.org/GNOME/glib/-/jobs/2579411
- https://gitlab.gnome.org/GNOME/glib/-/jobs/2578792
- https://gitlab.gnome.org/GNOME/glib/-/jobs/2579220
- https://gitlab.gnome.org/pwithnall/glib/-/jobs/2588507
I was looking at trying to diagnose some of these failures in order to
potentially file bugs against Meson, but the first step is really to
test against the latest version of Meson. So here we are.
Crucially, our other CI jobs continue to use the minimum Meson version
required by GLib, so we continue to test that GLib builds with its
minimum dependencies. I do not plan to change that.
Also crucially, this MR continues to use a specific Meson version,
rather than asking `pip` to install the latest available. Doing that
could lead to unexpected regressions in future, and that’s not what
GLib’s CI is meant to be testing for.
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
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>
This doesn’t enforce licensing/copyright headers to be present on all
files, but does check that at least a minimum number of files are
correct.
This should help avoid new files being added without appropriate
licensing information in future.
The baseline is set at what `reuse lint` outputs for me at the moment.
See https://reuse.software/tutorial/#step-2 for information about how to
add REUSE-compliant licensing/copyright to files.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
-Wnonnull is sort of fickle and it's an option a lot of consumers
of glib use.
This commit makes sure it gets used on linux during CI as well, so
we can catch compat problems before they hit our users.
To better reflect its purpose.
This will also help distinguish it from a job being added in a following
commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Setting installed_tests option enforces various test files to be
installed, this causes meson to build tools that might have not built
otherwise but that are still required for testing.
Also, disabling installed tests lead to slightly different code paths
when it comes to using test test files.
So, disable it for debian so that we can ensure that at test time we
have set all the dependencies between test programs and the used
resources (that can be libraries, external programs or modules).
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 were regressing on Python style too often. Since Python code style is
a lot easier to enforce than C code style, split it (and the shellcheck
checks) out from `style-check-diff` into a new CI job which is allowed
to fail the pipeline.
Only trigger it when .sh or .py files have changed, which should reduce
resource consumption.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This disables the following warning, which was causing CI failures on
macOS when building the libpcre2 subproject:
```
../subprojects/pcre2-10.40/src/pcre2_error.c:66:3: error: string literal of length 4380 exceeds maximum length 4095 that ISO C99 compilers are required to support [-Werror,-Woverlength-strings]
```
We don’t want to explicitly rely on using overlength strings in GLib,
which is why this change is a `CFLAGS` in the CI configuration, rather
than setting a project-level argument in `meson.build`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since the macOS CI jobs are run on a machine which isn’t using a
pre-made container image, we can’t ship a cached version of the
subproject, so it has to be pulled as a git submodule.
GitLab doesn’t do that by default unless you set
`GIT_SUBMODULE_STRATEGY` to something other than `none`.
See https://docs.gitlab.com/ee/ci/git_submodules.html
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is in preparation for porting `GRegex` to libpcre2, which is
happening in !2529. It’s a big port, though, and specially rebuilding
the CI images to add libpcre2 for it is a pain.
Add libpcre2, and then !2529 can drop the old libpcre dependencies when
the port lands.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1085
This means we can specify the standard options for testing GLib under
valgrind consistently, so that developers can use `meson test
--setup=valgrind` to run them.
Port the existing valgrind CI to use them (this will not change its
functional behaviour).
Suggested by Marco Trevisan at
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2717#note_1478891.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
iconv is complicated to look up. That complexity now resides in
Meson, since 0.60.0, via a `dependency('iconv')` lookup, so use that
instead.
No effort is made to support the old option for which type of iconv to
use. It was a false choice, because if only one was available, then
that's the only one you can use, and if both are available, the external
iconv shadows the builtin one and renders the builtin one unusable,
so there is still only one you can use.
This meant that when configuring glib with -Diconv=libc on systems that
had an external iconv, the configure check would detect a valid libc
iconv, try to use it, and then fail during the build because iconv.h
belongs to the external iconv and generates machine code using the
external iconv ABI, but fails to link to the iconv `find_library()`.
Meson handles this transparently.
Rather than carrying the copylib around inside GLib, which is a pain to
synchronise and affects our code coverage statistics.
This requires updating the CI images to cache the new subproject,
including updating the `cache-subprojects.sh` script to pull in git
submodules.
It also requires adding `gioenumtypes_dep` to be added to the
dependencies list of `libgio`, since it needs to be build before GVDB as
it’s pulled in by the GIO headers which GVDB includes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2603
They are [currently
failing](https://gitlab.gnome.org/GNOME/glib/-/jobs/2032874) with the
error:
```
1/273 glib:glib / array-test FAIL 0.19s killed by signal 11 SIGSEGV
05:04:16 G_DEBUG=gc-friendly G_TEST_BUILDDIR=/builds/GNOME/glib/_build/glib/tests MALLOC_CHECK_=2 MALLOC_PERTURB_=133 G_TEST_SRCDIR=/builds/GNOME/glib/glib/tests valgrind --tool=memcheck --error-exitcode=1 --track-origins=yes --leak-check=full --leak-resolution=high --num-callers=50 --show-leak-kinds=definite,possible --show-error-list=yes --suppressions=/builds/GNOME/glib/tools/glib.supp /builds/GNOME/glib/_build/glib/tests/array-test
----------------------------------- output -----------------------------------
stderr:
valgrind: m_libcfile.c:66 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed.
------------------------------------------------------------------------------
```
I’m not really sure what that means, but `show-execution-environment.sh`
says the FD soft limit is set to 524288 on the CI machine. That seems
high; on my machine it’s only 1024 (and the valgrind tests pass). So
let’s try 1024.
The valgrind CI has been failing since we most recently upgraded the CI
image to a new version of Fedora.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The runner machine is offline and there is no ETA on when it will be
back, so disable the CI job which uses it for now so that pipelines
can proceed.
See https://gitlab.gnome.org/Infrastructure/GitLab/-/issues/558
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Meson used to try and guess at the Python path. While this worked fine
for GLib before, it probably didn’t work 100% for other projects, so
Meson have made it an explicit option.
Set that option with the Python path used on the Windows CI machines.
This fixes a Meson warning with Meson >0.60.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
