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")
These are typically files generated by the gobject-introspection dumper,
which we don’t want to scan as they are not part of GLib’s runtime code.
For example:
```
/builds/GNOME/glib/_scan_build/meson-private/tmpr3jwvyib/tmp-introspect5dmnb_je/GObject-2.0.c:799:27: warning: Access to field 'message' results in a dereference of a null pointer (loaded from variable 'error') [core.NullDereference]
799 | g_printerr ("%s\n", error->message);
| ^~~~~~~~~~~~~~
1 warning generated.
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes commit 93271385f9.
Previously the `before_script` from `.build-linux` was used in whole for
these two jobs, but since the `.build-gobject-introspection` template
was also added, the `before_script`s from the two templates need to be
explicitly combined.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3458
Remove cmake as we no longer need to build ninja. We can use the
official wheel now since the runner's Python is 3.9 (before: 3.8).
Use the same comment regarding '--wrap-mode' as in the other jobs.
Download and use official ccache binary.
Add myself to the 'only' section in .gitlab-ci.yml so I can have
CI in my fork.
Disable a few deprecation warnings due to the much newer SDK of
the Apple Silicon machine.
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.
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
Since we run tests in parallel we may end up rewriting the coverage info
while running files acting on the same source files.
The compiler can be smart though, so let's use the proper flag.
Despite this, sometimes we may still end up into negative reports, so
let's ignore them in CI since it's not worth breaking the build because
of these coverage-parsing failures.
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
It seems to have been accidentally enabled by the switch to making
dtrace a Meson feature. This has only just been caught because the
FreeBSD CI runner has been offline for several weeks (see
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/1503).
With dtrace enabled, the FreeBSD CI build fails with:
```
[8/1601] Generating 'gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o'
FAILED: gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o
/usr/sbin/dtrace -G -s ../gobject/gobject_probes.d -o gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o
dtrace: failed to link script ../gobject/gobject_probes.d: No probe sites found for declared provider
[9/1601] Generating 'glib/libglib-2.0.so.0.8100.0.p/glib_probes.h' (wrapped by meson because command contains newlines)
[10/1601] Generating 'glib/libglib-2.0.so.0.8100.0.p/glib_probes.o'
FAILED: glib/libglib-2.0.so.0.8100.0.p/glib_probes.o
/usr/sbin/dtrace -G -s ../glib/glib_probes.d -o glib/libglib-2.0.so.0.8100.0.p/glib_probes.o
dtrace: failed to link script ../glib/glib_probes.d: No probe sites found for declared provider
```
(see https://gitlab.gnome.org/GNOME/glib/-/jobs/3961782)
I have no idea how to fix that, and it’s presumably not been working for
a long time.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It seems to have been accidentally enabled by the switch to making
dtrace a Meson feature. This has only just been caught because the
FreeBSD CI runner has been offline for several weeks (see
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/1503).
With dtrace enabled, the FreeBSD CI build fails with:
```
[8/1601] Generating 'gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o'
FAILED: gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o
/usr/sbin/dtrace -G -s ../gobject/gobject_probes.d -o gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o
dtrace: failed to link script ../gobject/gobject_probes.d: No probe sites found for declared provider
[9/1601] Generating 'glib/libglib-2.0.so.0.8100.0.p/glib_probes.h' (wrapped by meson because command contains newlines)
[10/1601] Generating 'glib/libglib-2.0.so.0.8100.0.p/glib_probes.o'
FAILED: glib/libglib-2.0.so.0.8100.0.p/glib_probes.o
/usr/sbin/dtrace -G -s ../glib/glib_probes.d -o glib/libglib-2.0.so.0.8100.0.p/glib_probes.o
dtrace: failed to link script ../glib/glib_probes.d: No probe sites found for declared provider
```
(see https://gitlab.gnome.org/GNOME/glib/-/jobs/3961782)
I have no idea how to fix that, and it’s presumably not been working for
a long time.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s not needed, and is now failing with:
```
meson.build:2578:36: ERROR: Feature systemtap cannot be enabled: Cannot enable systemtap because dtrace feature is disabled
A full log can be found at /builds/GNOME/glib/_build/meson-logs/meson-log.txt
```
See https://gitlab.gnome.org/GNOME/glib/-/jobs/3901860
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Now systemtap can be enabled by default in distros that use
-Dauto_features=enabled or for developers who already have systemtap
installed, while it's still disabled for developers who do not have
systemtap installed. See #3354
Now dtrace can be enabled by default in distros that use
-Dauto_features=enabled or for developers who already have dtrace
installed, while it's still disabled for developers who do not have
dtrace installed. See #3354
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>
Several of the assertions in GLib (particularly on hot paths in
`gobject.c`) are protected behind `#if G_ENABLE_DEBUG`. In order for
scan-build to see them, the scan-build CI job needs to make sure that
a debug build is definitely enabled — not just rely on it being
implicitly enabled via the combination of other build options.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
Eventually, we do want to include them in static analysis (their code is
run in the same process as GLib, after all). But for now, that’s too
much work to get started.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
It’s not highlighting severe bugs for us, and currently generates 132
out of 172 of the scan-build reports, so let’s disable it for now.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
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
Deriving from two templates means the `before_script` from the second
one overrides, rather than adding to, the one from the first.
Avoid that when using `.build-linux` and `.with-git` by explicitly
joining both scripts.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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
Even if we get warnings from the first lint check, we probably want to
see the warnings from later lint checks too, to reduce the number of
round-trips.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
For the same reasons as in commit 71061fdcb3, but in this
case we can’t downgrade the version of Meson on the CI runner, so just
tell it to shut up instead.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3238
Don’t allow the `pages` job to be run (even manually) on post-merge
pipelines. It’s not particularly useful, and GitLab doesn’t like having
a manual job with unsatisfied dependencies in a pipeline:
```
'pages' job needs 'coverage' job, but 'coverage' is not in any previous stage
'pages' job needs 'style-check-advisory' job, but 'style-check-advisory' is not in any previous stage
```
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3847#note_1986044
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In some merge requests there are bits (such as memory leaks) that we may want
to test before merging and that the schedules will run them.
As per this add a rule to make them manual, and apply it to some jobs.
