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>
Move the lcovrc file to the root of the project, so that it’s picked up
by Meson when running `ninja coverage` locally.
See https://github.com/mesonbuild/meson/issues/4628
This won’t affect the code coverage run on the CI, since that explicitly
used the lcovrc file already.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They are functionally quite similar, and combining them saves around 1
minute of CI runner time per pipeline, which is a nice saving for very
little downside.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The default is 30 days, but we don’t need them around that long. This
should free up some disk space on the GitLab/CI runner systems.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
libgamin was last released in 2007 and is dead
[upstream](https://gitlab.gnome.org/Archive/gamin). Distributions may
still ship it (although Fedora no longer does), but we want people to
use inotify on Linux since it’s actively supported.
BSDs use kqueue. Windows uses win32filemonitor.
FAM might still be used on some commercial Unix distributions, but there
are no contributors from those distributions, and certainly no CI for
them to prevent regressions.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2614
Don’t take the opportunity to add support for Android API 31 or update
the version of the Android NDK we’re using to r23b, though, as I
couldn’t quickly get that to work and ran out of time.
Bumping the Fedora version will at least reduce our CI repository disk
usage through sharing the base image.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2605
This is the oldest still-supported version of Fedora.
It no longer ships gamin.
This should fix the installed-tests, which rely on version 0.19 of
python-dbusmock. Fedora 33 only had 0.18.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Test failures were previously ignored on macOS because there are 12
tests which consistently fail (and have not yet been fixed, because
there are no regularly active macOS maintainers for GLib; you could help
here!).
However, this means that new test failures can’t be spotted.
So, explicitly mark those 12 tests as `should_fail` on macOS, and then
make other test failures cause failure of the CI run.
We can track the process of fixing those 12 tests on #1392 and #1251.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
Rather than running them on each commit on `main`. This saves resources.
Given that Android API 28 and FreeBSD 13 jobs continue to be run on each
commit on `main`, this seems like an acceptable tradeoff. It’s very
unlikely that a regression will happen which affects the older systems
and *not* the newer systems. If it does, it will be caught within a week
by the scheduled job.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This clarifies the intent of the `branches@GNOME/glib` selector. It
introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
As with a previous commit, `.only-default` does things which are
orthogonal to what `.build-linux` does, so it’s clearer and more
extensible for CI jobs to specify both in their top-level `extends`
statements, rather than relying on `.build-linux` to pull
`.only-default` in.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes the name a bit more descriptive, and makes it match the rest
of the naming scheme.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This name is more specific to what the template actually does.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`.build` and `.only-schedules` are orthogonal, and I want to use
`.only-schedules` together with `.cross-template` in future, which would
require creating more cross-product templates.
Avoid that by splitting `extends: .build-only-schedules` into
```
extends:
- .build
- .only-schedules
```
Multiple extends are supported by GitLab: https://docs.gitlab.com/ee/ci/yaml/#extends
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
They were needed for `GMemoryMonitor` support. That was first included
in the gobject-introspection 1.63.2 release and the xdg-desktop-portal
1.5.4 release. The Fedora 33 image we’re using for CI has versions
1.66.1 and 1.8.1.
This should speed up the `installed-tests` CI jobs a bit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
There are no compiler warnings when building on macOS CI at the moment,
so let’s keep it that way by turning any future ones into errors.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is an attempt to fix a persistent error on the macOS CI:
```
Objective-C compiler for the host machine: cc (clang 10.0.0)
Objective-C linker for the host machine: APPLE ld 409.12
WARNING: No include directory found parsing "cc -xobjc -E -v -" output
meson.build:761:2: ERROR: Fatal warnings enabled, aborting
```
For example, seen on https://gitlab.gnome.org/GNOME/glib/-/jobs/1618966.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is what’s available in the new Debian Stable, so we can expect it
to be available pretty much everywhere.
Subsequent commits will clean up old workarounds.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
