The status quo makes us manage the dependencies simultaneously in 3 ways: * in [craft blueprint](https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/extragear/kmymoney/kmymoney.py) for building binary packages in http://binary-factory.kde.org * in [kde-build-metadata](https://invent.kde.org/sysadmin/kde-build-metadata/-/blob/master/dependency-data-stable-kf5-qt5#L1372) by http://build.kde.org CI builds and [kdesrc-build](https://kdesrc-build.kde.org) tool * directly in repository in [3rd party](3rdparty) folder, used by a [script](packaging/linux/appimage) 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](https://vcpkg.readthedocs.io/en/latest/) 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](https://github.com/microsoft/vcpkg/issues/10228) for sqlcipher) or their actual project owners. 4. integration with build systems 5. integration with IDEs ([VS](https://docs.microsoft.com/en-us/cpp/build/vcpkg?view=vs-2019)) 6. designed to be used with cmake 7. open-source, maintained by Microsoft 9. Well-supported by QT itself: https://resources.qt.io/youtube-all-videos-2/using-cmake-and-vcpkg-in-qt-application-development 10. 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](https://github.com/microsoft/vcpkg/tree/master/ports) at the time of writing this 11. 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 12. Reduction of "Not Invented Here" technical debt 15. Potentially enabling CI builds on build.kde.org for Windows and macOS 16. Making CI builds compile using all dependencies and plugins, not just the [bare minimum ](https://invent.kde.org/sysadmin/kde-build-metadata/-/blob/master/dependency-data-stable-kf5-qt5#L1372) 17. Support for binary builds, library versioning and private repositories [is on the roadmap](https://devblogs.microsoft.com/cppblog/vcpkg-2020-04-update-and-product-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: * [x] create recipes for libraries currently missing in [vcpkg repository](https://github.com/microsoft/vcpkg/tree/master/ports), e.g. `libaqbanking` or `libgwenhywfar` and [requesting their addition ](https://vcpkg.readthedocs.io/en/latest/maintainers/maintainer-guide/) * [x] 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) * [x] also to libofx maintainers * [ ] potentially also worth reaching out to GnuCash, since they use a similar set of dependencies and [have discussed](http://gnucash.1415818.n4.nabble.com/GNC-dev-Building-on-Windows-tp4712455p4712685.html) vcpkg in recent past * [x] update existing and add all missing KF5 ports: https://invent.kde.org/wrobelda/vcpkg/-/milestones * [x] ~~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