Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • KMyMoney KMyMoney
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 38
    • Issues 38
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 11
    • Merge requests 11
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OfficeOffice
  • KMyMoneyKMyMoney
  • Issues
  • #23
Closed
Open
Issue created Jun 19, 2020 by Dawid Wrobel@wrobeldaDeveloper5 of 6 checklist items completed5/6 checklist items

Add support for vcpkg for managing build dependencies

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

  • in craft blueprint for building binary packages in http://binary-factory.kde.org
  • in kde-build-metadata by http://build.kde.org CI builds and kdesrc-build tool
  • directly in repository in 3rd party folder, used by a script that prepares and builds AppImage

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:

  • https://github.com/microsoft/vcpkg/pull/11861
  • https://blog.hellozee.dev/tussling-with-vcpkg/

Related issues:

  • #3
  • #11

Required tasks:

  • create recipes for libraries currently missing in vcpkg repository, e.g. libaqbanking or libgwenhywfar and requesting their addition
    • worth reaching out to AqBanking themselves, hopefully they'd be interested in maintaining their own recipes and are best suited to do so (DONE: https://www.aquamaniac.de/rdm/issues/214)
    • also to libofx maintainers
    • potentially also worth reaching out to GnuCash, since they use a similar set of dependencies and have discussed vcpkg in recent past
    • update existing and add all missing KF5 ports: https://invent.kde.org/wrobelda/vcpkg/-/milestones
  • 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 Sep 18, 2021 by Dawid Wrobel
Assignee
Assign to
Time tracking