A few years back, I shifted kdesrc-build to a release model where it was to be used essentially straight from the git-master version. This was both beneficial from a time management perspective, and also reflected the ongoing reality of how it was actually being used, since most developers were using kdesrc-build directly from git by then to take advantage of ongoing updates to the sample KF5 configurations.
While this was helpful to free up more time for development, it also meant that release announcements stopped being published. Since things that aren’t written down somewhere might as well have never happened, I figured I’d go ahead and collect some of the more notable changes over the past couple of years.
--include-dependencies(a flag to automatically pull in KDE-based repository dependencies into a build) was adapted to find any KDE-based repository, instead of only ones that could already be located somewhere within your configuration file. The intent to this was to permit even simpler configuration files (set your source-dir, install dir, and go… at least in concept).- Update the code to refer consistently to the kdesrc-build docs available at docs.kde.org rather than kdesrc-build.kde.org. The former are always built (from the same
doc/sources in kdesrc-build.git) and were much better maintained. - Added a
--queryflag to the script. This flag permits retrieving information about the various git repositories without having to dust off scripts in kde-dev-scripts or kde-build-metadata, or go through a full kdesrc-build run. Note that you should probably include the--pretendflag to get output suitable for use by automated scripts, and kdesrc-build is not very fast on this. - Fixed the
${option-name}syntax in the configuration file, which permits referring later in the configuration file to options previously set, including options not recognized by kdesrc-build. - Allowed
optionsblocks in the configuration file to apply to entire (named) module sets, not just individual modules. Of course, you’ll want to be careful not to have ambiguous names between module sets and modules… - Removed support for installing KDE git repositories from tarball snapshots. This was far more useful back when we used Subversion; with git it actually seems to take more system resources to generate the tarballs than it saves on the whole, so the KDE sysadmins stopped generating them last year, and there are no other users supported by kdesrc-build. Much of the code has been removed already, the rest will be removed as I get to it.
- Some work to move the included
kdesrc-build-setupscript to belated point to Qt5-based repositories and branches. The most ideal option is probably still to have kdesrc-build itself either work with a built-in good default configuration, or to generate a sample config directly… but that needs someone to do the work. - The normal set of code refactorings. Five years ago, when I started trying to modularize the core script with commit 88b0657, kdesrc-build was a 9,304 line single monolithic Perl script. I had started to get concerned at the time that if I ever left maintenance of the script, or if we needed to port it away from Perl, that it would be very difficult to make that transition. While the script is not exactly straightforward even today, it is in much better shape and I hope to keep that going.
- Also, I have finally committed some work I’d been pursuing off and on over the past year, to remove the use of the
kde_projects.xmlfile that kdesrc-build used to gather metadata about the various KDE source repositories. At one point it was looking like I’d be using a dedicated Web API that would expose this repository metadata, but then we realized that it would be easier for all involved to just go straight to the source: the sysadmin/repo-metadata.git repository. That code landed earlier this week, and although I’ve already received a couple of bug reports on it, it will significantly ease the burden on the KDE build infrastructure both in terms of compute power and of sysadmin time in maintaining the script which generates the required XML as they evolve their own backend.- You’ll want to install the
YAML::XSPerl module. On Debian/Ubuntu based systems this seems to be libyaml-libyaml-perl. In particular the plainYAMLPerl module seems to be buggy, at least for the YAML we are using in our repo-metadata.
- You’ll want to install the
- Finally, while this support still remains ‘unofficial’, I have managed to get enough of the Qt5 build system working in kdesrc-build that I have been able to start locally keeping Qt5 up to date with kdesrc-build and only a minimal amount of manual updates (usually revolving around git submodules).
That’s quite a bit of work, but my personal effort represents less than 2/3rds of the git commits made in the last 2 years. The KDE community at large have been instrumental in keeping the default build configuration up to date and fixing bugs in the script itself.
Going forward my major goals are to resurrect a useful test suite (something broken in the modularization effort), and to use that to support making the script significantly less noisy (think one line of output per module, tops).
Both of these efforts have already started to some extent, and the test suite has its own branch (“testing-restructure”).
That’s what I want to do… what do you think I should do? How should kdesrc-build continue to evolve to support the KDE Community?