Nico's blog

As you may know KDE consists of many different subprojects, where some projects depend on other projects. Most KDE projects depend on some KDE Frameworks, but other dependencies are also possible, e.g. plasma-desktop depends on plasma-workspace. To be able to automate building projects (for the CI system or tools like kdesrc-build) you need a machine-readable source of dependency information.

For a long time this information has been available in a set of files in repo-metadata. To declare for example plasma-desktop’s dependency on plasma-workspace one would write the line

kde/workspace/plasma-desktop: kde/workspace/plasma-workspace


to the relevant file.

Since most projects depend on a lot of KDE Frameworks, and specifying each of the frameworks manually is somewhat cumbersome, a virtual frameworks/kf5umbrella project that depends on all frameworks was introduced. By default all projects depend on this helper project. This metadata was used both by the Jenkins-based build.kde.org CI and kdesrc-build.

The approach worked well enough, but had some drawbacks. First of all most projects don’t actually depend on all frameworks, so kdesrc-build would build projects that you don’t actually need, which is wasteful. Second, the format had no way for platform-specific adjustments, like defining that X depends on Y on Linux but not Windows. This was especially problematic for our Android builds, where it would try to build projects that don’t actually support Android or weren’t needed but increasing the size of the final APK. This problem was solved by moving our Android builds to use Craft, which maintains its own dependency metadata.

Because of these shortcomings when we replaced our Jenkins-based CI with Gitlab CI sysadmins came up with a new way of defining dependencies for each project. Instead of a single, global file with all information each project now has a .kde-ci.yml file in its repository that defines the dependencies. There is no equivalent of the kf5umbrella any more, which forces projects to explicitly list all of their frameworks dependencies. The new format also allows to define platform-specific dependency information. For example Neochat’s .kde-ci.yml looks like this:

Dependencies:
- 'on': ['@all']
'require':
'frameworks/extra-cmake-modules': '@stable'
'frameworks/kirigami': '@stable'
'frameworks/ki18n': '@stable'
'frameworks/kconfig': '@stable'
'frameworks/syntax-highlighting': '@stable'
'frameworks/kitemmodels': '@stable'
'libraries/kquickimageeditor': '@stable'
'frameworks/sonnet': '@stable'
'third-party/libquotient': '@latest'
'third-party/qtkeychain': '@latest'
'third-party/cmark': '@latest'

- 'on': ['Windows', 'Linux', 'FreeBSD']
'require':
'frameworks/qqc2-desktop-style': '@stable'
'frameworks/kio': '@stable'
'frameworks/kwindowsystem': '@stable'
'frameworks/kconfigwidgets': '@stable'

- 'on': ['Linux', 'FreeBSD']
'require':

However, kdesrc-build still uses the old dependency infomation. As it is natural for two instances of the same information, they eventually got out of sync and the metadata used by kdesrc-build got more and more incorrect. Something had to be done. Due to its architecture it isn’t really feasible for kdesrc-build to directly read the .kde-ci.yml files since that would require cloning the repos to read the data. Instead we opted to generate the old-style dependency data from the .kde-ci.yml files. In an attempt to learn Rust I wrote a tool that does this and committed the initial result. In the spirit of the recently announced Automation Goal this ought to be automated fully, but that’s for another day.
Any missing information in the generated data should be fixed by adding it to the relevant .kde-ci.yml file. If you find any other issues with the generated data please let me know.