On GTK3 the msys2-mingw64-meson job is failing due to error:
mingw-w64-x86_64-pkg-config and mingw-w64-x86_64-pkgconf are in
conflict. Remove mingw-w64-x86_64-pkgconf? [Y/n]
To fix this we change required package pkg-config to pkgconf, which
is what the GTK4 branch also uses.
CI and downstream packagers have been using the Meson build for a while
now, and we checked that it's idempotent to the Autotools build.
Having two build systems in tree doesn't make maintaining and releasing
GTK any easier, even if it's the stable/frozen branch.
There are two possible interpretations of "expected failure": either
the test *must* fail (exactly the inverse of an ordinary test, with
success becoming failure and failure becoming success), or the test
*may* fail (with success intended, but failure possible in some
environments). Autotools had the second interpretation, which seems
more useful in practice, but Meson has the first.
In GTK 3.24.35, if the environment is such that the label-sizing.ui
reftest happens to be successful, the overall result of the test suite
is failure. This seems unlikely to have been the intention.
Instead of using should_fail, put the tests in one of two new suites:
"flaky" is intended for tests that succeed or fail unpredictably
according to the test environment or chance, while "failing" is for
tests that ought to succeed but currently never do as a result of a
bug or missing functionality. With a sufficiently new version of Meson,
the flaky and failing tests are not run by default, but can be requested
with a command like:
meson test --setup=unstable_tests --suite=flaky --suite=failing
This arrangement is inspired by GNOME/glib!2987, which was contributed
by Marco Trevisan.
Signed-off-by: Simon McVittie <smcv@debian.org>
Enabling one backend (Broadway, in commit 1882ff9b) implicitly disabled
all the others, which was probably not intentional. Bring the Autotools
build into line with Meson.
Signed-off-by: Simon McVittie <smcv@debian.org>
I couldn't get all reftests to work reliably, so the tests failing
on either CI or on my machine are skipped for now.
Installed tests are disabled by default and can be enabled with "-Dinstalled_tests=true"
This can be used to verify that we can build a release tarball using
Autotools, without being subject to known-failing tests (which are less
straightforward to fix). Since commit 44a2d5d6 the Meson build skips
the failing a11y tests, but we don't have an equally easy mechanism
to skip those on Autotools.
Signed-off-by: Simon McVittie <smcv@debian.org>
Enabling one backend (Broadway, in commit 1882ff9b) implicitly disabled
all the others, which was probably not intentional. Bring the Autotools
build into line with Meson.
Signed-off-by: Simon McVittie <smcv@debian.org>
getting_started.xml uses relative paths for including code examples
and for some reason the base path is different with meson than with autotools.
Switch both autotools and meson to generate the file and insert the absolute
source path instead.
This also cleans up the content file list: the expand content files have to
be in the content file list as well, so just append them there.
This changes the configure option into two states:
auto: build all that can be build (default)
A list of backend names: build them and fail if we can't
"papi" is missing because it's not in Debian and I can't test it.
