...in the main tests that we expect to pass.
Due to an upstream issue in PCRE2-10.44, disable running the PCRE2 tests for
now, until the next release (or so) of PCRE2, as the issue has already been
resolved in upstream PCRE2 but has not made it to the PCRE2 release that we use
for our subprojects.
...and add ability to select target platform for calling vcvarsall.bat,
so that we can accomodate 32-bit builds and possibly ARM64 builds in the
CI if we need to.
We want to build GLib against a matched version of
gobject-introspection, and this version will probably be bumped quite
often as the two are developed in tandem.
However, if the CI system provides a newer version, we should probably
use that, otherwise we’re essentially downgrading part of the OS on the
CI system, and that probably will result in issues. In particular,
gobject-introspection <1.82 has a bug on MSYS2 which means it doesn’t
build (see issue #3464).
So, build gobject-introspection manually if the CI system version is too
old, otherwise use the system version. Do this programmatically so we
don’t have to repeatedly add and remove the gobject-introspection build
commands from the CI configuration as versions are bumped.
Fixes: #3464
It's better to warn by default on MSVC (which we were already doing before
we bumped to 1.4.0) than to fail by default on macOS.
Fixes: 51e3e7d9ae ("build: Bump Meson dependency to 1.4.0")
Meson 1.5.1 is available in the fd.o SDK and in Debian testing, so the
glib Meson policy says we can update. Update the minimum only as far as
1.4.0 because we don't yet have a need for 1.5.0.
This allows us to:
- Use file.full_path() to avoid deprecation warnings on str.format(file).
- Set c_std=gnu99,c99 to avoid deprecation warnings with gnu99 on MSVC.
Update all the CI builds to use the latest 1.4.x patch release, 1.4.2.
The FreeBSD runner cannot be updated via `gitlab-ci.yml`, so will be
broken for now.
Similarly, the macOS build will not work unless `-Dc_std=gnu99` is
specified at configure time, due to
https://github.com/mesonbuild/meson/issues/13639.
The build instructions for msys2 builds are stored outwith
`.gitlab-ci.yml`.
We need to build a specific (recent) version of gobject-introspection so
we can get support for async annotations in `g-ir-scanner`. See !3746.
Fixes commit 93271385f9.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Also start using a more reliable versioning scheme for the fedora images
so that the tag is always vFEDORA_VERSION.IMAGE_VERSION to make it
easier to understand on future updates
Fixes: #3381
When using dtrace some temporary files may be leaked as source files and
this may lead to build issues such as
geninfo: ERROR: unable to open
/builds/GNOME/glib/_build/.dtrace-temp.ed1c5ba9.c:
No such file or directory
AFAIK there's no way to keep these temporary files around, so the only
thing we can do is making lcov less strict about missing files.
We can drop the special option from genhtml since it's using the same
lcovrc file
Fedora 37 is out of support so, as per our policy, update the CI image
to the oldest still-supported release, which is 39.
Update the mingw CI image too, as it’s built on top of the Fedora one.
Update the supported platforms documentation (and fix the Debian version
listed there to match what’s currently in CI, which is up to date).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
They cause too much noise at the moment. I want to make scan-build
messages fatal, and with 66 of 238 reports coming from the tests,
that’s not currently feasible.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
The `gi-docgen` tool is not designed to be used like that. In
particular, when nesting documentation directories, the generated
`*.devhelp2` files (needed by Devhelp to show the documentation) are
nested one directory level too deep for Devhelp to find them, and hence
are useless, and the documentation doesn’t show up in this common
documentation viewer.
So, change the installed documentation directory hierarchy:
* `${PREFIX}/share/doc/glib-2.0/gio` → `${PREFIX}/share/doc/gio-2.0`
* `${PREFIX}/share/doc/glib-2.0/glib-unix` →
`${PREFIX}/share/doc/glib-unix-2.0`
* `${PREFIX}/share/doc/glib-2.0/gobject` →
`${PREFIX}/share/doc/gobject-2.0`
* etc.
* `${PREFIX}/share/doc/glib-2.0/glib` → `${PREFIX}/share/doc/glib-2.0`
This is going to seem like pointless churn (the contents of the
documentation have not changed), and packagers may mourn the split of
content in `/usr/share/doc` from `/usr/share/doc/${package_name}` to
`/usr/share/doc/${pkg_config_id}` instead, but that seems to be the best
approach to fix this issue in GLib. gi-docgen’s behaviour does feel
fairly consistent and correct with the rest of how it works (single
output directory).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3287
For the same reasons as in commit 71061fdcb3, but in this
case we can’t downgrade the version of Meson on the CI runner (see the
previous commit), so just tell it to shut up instead.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3262
Rather than pinning it to the lowest version we support, as is the
standard policy.
This means we’ll end up using version 1.3.2-2, which has just been
packaged to contain the fix for
https://github.com/mesonbuild/meson/issues/12330, which has been
impacting GLib significantly since we started installing
gobject-introspection in CI in commit
c428d6e673.
Thanks to Christoph Reiter, Luca Bacci and Simon McVittie for diagnosing
and fixing this issue.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3262
Enable the msys2-mingw32 CI job for merges, just like the fedora-x86_64
job is. The pair of them can then build the platform specific GIR and
documentation files.
The `download-reference.sh` script in the `docs-gtk-org` branch of GTK
can then download the docs as an artifact from the latest GLib build of
`main`, and publish them on docs.gtk.org, as is currently done for the
platform agnostic documentation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
This reverts commit 94273b0ebf.
Meson 1.2.0 contains a fix for the underlying issue (in commit
bd3d2cf91894b1f91128011b2cf56a5bd2c326ae), and we now depend on 1.2.0.
So the workaround is no longer needed.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This will make it easier and more obvious for developers to run them
locally: I'm sure I'm not the only developer who had assumed that
`.gitlab-ci/` is private to the CI environment and inappropriate (or
perhaps even destructive) to run on a developer/user system.
The lint checks are automatically skipped (with TAP SKIP syntax) if we
are not in a git checkout, or if git or the lint tool is missing. They
can also be disabled explicitly with `meson test --no-suite=lint`,
which downstream distributions will probably want to do.
By default, most lint checks are reported as an "expected failure"
(with TAP TODO syntax) rather than a hard failure, because they do not
indicate a functional problem with GLib and there is a tendency for
lint tools to introduce additional checks or become more strict over
time. Developers can override this by configuring with `-Dwerror=true`
(which also makes compiler warnings into fatal errors), or by running
the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`.
One exception to this is tests/check-missing-install-tag.py, which is
checking a functionally significant feature of our build system, and
seems like it is unlikely to have false positives: if that one fails,
it is reported as a hard failure.
run-style-check-diff.sh and run-check-todos.sh are not currently given
this treatment, because they require search-common-ancestor.sh, which
uses Gitlab-CI-specific information to find out which commits are in-scope
for checking.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This allows the tests to be run with `meson test --setup thorough` and
it will run all the GTest tests with `-m thorough`.
Since this argument isn’t supported by the Python tests, it’s not passed
to them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Previously, `-Dman=false` was the default, because the generated man
pages were shipped in the distribution tarball already, so the option
actually mostly controlled whether to *re*build them.
The generated pages are no longer shipped in the tarball (and probably
haven’t been since the port to Meson, though I haven’t checked), so it
makes sense to change the default to encourage building the man pages if
the right tooling (`rst2man`) is available.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In most CI builds. (Not all of them, though, so we can also test the
build works with it disabled.)
This is needed for the upcoming libgirepository tests, as they need some
GIR files to test against.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Alpine 3.19 ships with Meson 1.3.0, which has broken handling of File
objects and their paths. This causes (as far as I can tell)
un-work-around-able breakage of GLib’s build.
See https://github.com/mesonbuild/meson/issues/5273#issuecomment-1851811417
That should be fixed in Meson 1.4.0, but that might not be released for
a while. Because we’re here to test GLib, not Meson, let’s pin the Meson
version in the Alpine CI image to 1.2.3, which we know works and is
reasonably up to date (and is what the other CI images use).
Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/3361388
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The changes in commit 95479256df didn’t
completely work (or some other change has broken them since): the
informational message at the end of the script is now not printed.
Fix that by stopping bash exiting immediately if the subshell exits, by
using it in a boolean expression.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The `%E` modifier causes dates to be formatted using an alternative era
representation for years. This doesn’t do anything for most dates, but
in locales such as Thai and Japanese it causes years to be printed using
era names.
In Thai, this means the Thai solar calendar
(https://en.wikipedia.org/wiki/Thai_solar_calendar). In Japanese, this
means Japanese era names
(https://en.wikipedia.org/wiki/Japanese_era_name).
The `%E` modifier syntax follows what’s supported in glibc — see
nl_langinfo(3).
Supporting this is quite involved, as it means loading the `ERA`
description from libc and parsing it.
Unit tests are included.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3119
And update all the CI builds to use the latest micro release from that
series, 1.2.3.
This version bump means we can:
- Drop some backwards-compatibility Meson checks
- Fix a periodic CI failure caused by a now-fixed Meson bug
(https://github.com/mesonbuild/meson/pull/10633)
It’s in line with our [Meson version policy](./docs/meson-version.md),
as Meson 1.2.1 is available in
[Debian Trixie](https://packages.debian.org/source/trixie/meson) and the
[freedesktop SDK](c95902f2ed/elements/components/meson.bst).
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
The alt-digits are loaded from `nl_langinfo()` in a `GOnce` section,
which means `nl_langinfo()` is not re-queried after the process changes
locale (if that happens).
So, change the `GOnce` to a mutex and store the locale of the alt-digits
alongside them. This will introduce contention when calling
`format_number()` is called, but how often are multiple threads trying
to format dates at the same time?
If this does get highlighted as a performance problem, the other
approach I considered was a `GPrivate` struct containing all the
locale-specific cached data. That comes at the cost of using a
`GPrivate` slot (although that’s only particularly expensive on Windows,
and the locale code is quite different for Windows, so perhaps that
could be avoided entirely). It does mean that all locale printing could
be lock-free and still safely update cached data on a locale change.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since upgrading to Debian Bookworm in 13c359536, `clang-format-14` is
what’s available in the CI image.
This should fix the style-check-advisory CI job.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
