Skip to content

GitLab

Closed
Created by Dawid Wróbel@wrobeldaDeveloper5 of 6 tasks completed5/6 tasks

Add support for vcpkg for managing build dependencies

The status quo makes us manage the dependencies simultaneously in 3 ways:

And yet none of these can be realistically used to prepare a dev environment and make things easier for the actual developers themselves. This could be for the most part solved by leveraging vcpkg to automatically handle as many dependencies as possible.

The advantages are:

  1. easy onboarding for new developers with coherent, platform-agnostic instructions: the only single thing they explicitly have to do is to pass a cmake switch (-DCMAKE_TOOLCHAIN_FILE=/Users/dev/vcpkg/scripts/buildsystems/vcpkg.cmake)
  2. cross-platform support for each library out-of-the-box (Windows, Linux and MacOS), as opposed to having to use a platform-specific manager, e.g. apt (Debian/Ubuntu Linux) or Homebrew (macOS)
  3. reduced maintenance overhead
    • AppImage would only require a build-script, the dependencies would be handled by the main CMakeList.txt file in a standard way automatically by passing vcpkg-specific cmake switches.
    • craft blueprint would only define KDE's own packages as dependencies build and packaging instructions, the rest would be handled by the main CMakeList.txt file in a standard way
    • once added to vcpkg repository, due to its popularity, the packages that only we (KMM) use in KDE world would receive attention and contributions from the outside of it (see e.g. a request for sqlcipher) or their actual project owners.
  4. integration with build systems
  5. integration with IDEs (VS)
  6. designed to be used with cmake
  7. open-source, maintained by Microsoft
  8. Well-supported by QT itself: https://resources.qt.io/youtube-all-videos-2/using-cmake-and-vcpkg-in-qt-application-development
  9. 1400 packages in centralized (i.e. not prone to npm-like issues with several (un)maintained, crowd-sourced copies of the same package) vcpkg repository at the time of writing this
  10. The modern DevOps-as-Code approach to maintaining dependencies, as opposed to relying on decentralized external sources.
    • This allows to maintain branch-specific list of dependencies and their required versions without affecting other branches, which is currently impossible with craft blueprint residing in a separate project's repository
  11. Reduction of "Not Invented Here" technical debt
  12. Potentially enabling CI builds on build.kde.org for Windows and macOS
  13. Making CI builds compile using all dependencies and plugins, not just the bare minimum
  14. Support for binary builds, library versioning and private repositories is on the roadmap.

Krita is also in the process of migrating to vcpkg, too, and they added a bunch of ports for KF5 libraries:

Related issues:

Required tasks:

  • create recipes for libraries currently missing in vcpkg repository, e.g. libaqbanking or libgwenhywfar and requesting their addition
  • adding vcpkg to CMakeLists.txt build scripts for automatic downloading
    • It needs to be verified with distro packagers if and how this is possible. Some distros do not have internet access during package creation
    • vcpkg usage can also be simply not be enabled to make the KMM build chain default to distro's system-wide -dev packages: https://vcpkg.readthedocs.io/en/latest/examples/installing-and-using-packages/#cmake-toolchain-file
    • the 2020.07 version of vcpkg supports vcpkg.json manifest file. Once included in the source code, it contains a branch-specific list of the dependencies that are to be installed and bootstrapped. The only single thing a dev has to explicitly do is to add a cmake switch (-DCMAKE_TOOLCHAIN_FILE=/Users/dev/vcpkg/scripts/buildsystems/vcpkg.cmake), the rest is handled automatically.

The fine-grained tasks are tracked here: https://invent.kde.org/wrobelda/vcpkg/-/milestones

Edited by Dawid Wróbel