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.
Merge it with the `G_DISABLE_ASSERT` test run, to avoid tying up another
test runner for no particular benefit.
By running the thorough tests regularly, we’ll hopefully avoid them
atrophying again (see the previous few commits full of fixes to them).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The generated docs are discarded by `meson dist` after building the dist
tarball, so we need to compile them again. And they get generated in the
`_build` directory, not the source directory.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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>
It’s still going to be used on the `glib-2-78` branch because the
dependencies there are frozen, but since it’s EOL it can’t have
additional dependencies (like the Python `packaging` package) installed
for `main`, so let’s drop it. We have the FreeBSD 13 runner on `main`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3740#note_1957840
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This reverts commit 35ec6b6387.
The FreeBSD 13 CI runner now has the Python `packaging` package
installed, so should work again.
The FreeBSD 12 runner is EOL so can’t have that package installed, so
will be dropped from GLib `main` in the next commit.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3740#note_1957840
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>
So they are consistent with the way we’re building man pages in other
projects, and because some people are allergic to XML.
This changes the build-time dependencies from `xsltproc` to `rst2man`,
and also takes the opportunity to change the `-Dman` Meson option from a
boolean to a feature (so you should use `-Dman-pages={enabled,disabled}`
now, rather than `-Dman={true,false}`).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Not that this job is particularly maintained at the moment, but at least
try to keep it up to date.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Since it now has to build the docs (and code coverage) for `main`, that
needs to happen after branches are merged.
Other jobs remain not-run on merges.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
The actual deployment will be done by
https://gitlab.gnome.org/GNOME/gtk/-/blob/docs-gtk-org/; it pulls the
most recent artifact zip from glib.git.
This ensures that only one project/job/branch has push access to the
website.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
