Thanks to the work of Christoph Reiter, GLib has had continuous integration builds on Windows (using MinGW32/MSYS2) for a week or two now. Furthermore, he’s added code coverage support, so we can easily see how our code coverage is changing over time. Thanks Christoph!
Last Thursday and Friday was the GTK+ hackfest in Brussels. Matthias and Timm have blogged about GTK+ discussions already. This post is about the GLib side of things.
Firstly, we’re moving to Meson, but with no regressions from autotools. The plan is to target functional compatibility with autotools for 2.58, to keep both build systems in parallel for a release or two, and then drop autotools as soon as we can be satisfied there are no regressions for any of our features or supported platforms. I’d like to encourage distributions and developers to start trying to build GLib with Meson, seeing what breaks, and filing bugs.
Secondly, we’re migrating to gitlab, slowly. The first step is to migrate from cgit to gitlab, which will allow us to set up continuous integration for GLib. This will be a big win. The second step will be to migrate Bugzilla to gitlab. That’s going to take a bit longer, since there are issues with getting the data out of Bugzilla efficiently. All open bugs will be transferred, just like with the other gitlab transitions so far.
The maintainership status of GLib was also discussed. We are short on people power, and would appreciate assistance. If your project or company relies on GLib, please consider helping out with patch review or writing patches. We have three part-time maintainers who can provide guidance and help. We’re particularly interested in finding people to help maintain the platform ports of GLib, like Windows, OS X or BSD, more officially. Find us in #gtk+ on irc.gnome.org.
We also discussed a number of other, smaller features and issues, which might get handled for 2.58 depending on time. If you would like to work on any of them, please do! We can provide guidance and patch review in Bugzilla.
Thanks to Matthias and Emmanuele for organising the hackfest, Allison for turning up and imparting sage GLib wisdom, and Purism for kindly sponsoring dinner on Friday night.
Inspired by the talk at FOSDEM, I’ve just enabled GitLab’s continuous integration (CI) for building
make distcheck for Walbottle, and it was delightfully easy. The results are on Walbottle’s GitLab page.
- Create a
cibranch to contain the mess you’ll make while iterating over the correct compile steps.
- Create and push a
.gitlab-ci.ymlfile containing build rules similar to the following:
image: debian:unstable before_script: - apt update -qq - apt install -y -qq build-essential autoconf automake pkg-config libtool m4 autoconf-archive gtk-doc-tools libxml2-utils gobject-introspection libgirepository1.0-dev libglib2.0-dev libjson-glib-dev stages: - build # FIXME: Re-enable valgrind once running the tests under it doesn’t take forever (it causes timeouts). # Re-add valgrind to apt-install line above build-distcheck: stage: build script: - mkdir build - cd build - ../autogen.sh --disable-valgrind - make V=1 VERBOSE=1 - DISTCHECK_CONFIGURE_FLAGS=--disable-valgrind make distcheck V=1 VERBOSE=1 # The files which are to be made available in GitLab artifacts: paths: - build/*
- Iterate a few times until you get all the dependencies right.
- Fix any problems you find (because this might well find problems with your dependency declaration in
configure.ac, or other
distcheckproblems in your project).
masterand profit from CI results on every branch and master commit.
Looking at the
For information on the overall layout of the YAML file, and the phases available, you’re best off looking at the comprehensive GitLab documentation. Here are some notes about the autotools-and-C–specific bits of it:
imageis a Docker image; I picked a Debian one from the Docker hub.
- Package installation seems to need to be done in the
before_scriptphase, or the packages can’t be found (which is presumably a protection against rogue build systems).
- I chose to build
distcheckin my build rule because that runs the build, runs the tests, and tries various
builddirconfigurations. You can add other build targets (like
build-distcheckto try other build setups).
V=1 VERBOSE=1to get verbose build and test log output in your CI build logs, otherwise you will struggle to work out what is causing any failures.
- Note that
configureflags passed to
./configureare not automatically passed in again when
./configureis run as part of
distcheck— so use
DISTCHECK_CONFIGURE_FLAGSfor that. Ideally, your project will be less fragile than mine, and hence not need any of this.
- Export the whole
builddirectory as an artifact on success, so you can look at any of the build objects, or the generated tarball, or documentation. You could limit this (for example, to just the tarball) if you’re sure you’ll never need the rest of it.
libnice, everyone’s favourite ICE networking library, is now mirrored on GitHub (and GitLab), to make contributing to it easier — just submit a pull request. The canonical git repository is still on freedesktop.org.
Bug tracking is now on phabricator.freedesktop.org, which is where all new bugs should be reported. Existing open bugs have been migrated; existing closed bugs have not, and are archived on bugs.freedesktop.org.
We’ve been slowly working on some interesting changes to how GSockets are handled, so watch out for news on that.