**This is a meta task to track the progress in bringing the Framework libs to compatibility with static compilation**
As some of you may have noticed, we’re moving towards supporting static builds of KDE software, starting with the frameworks.
Over past ~12 months a groundwork has been laid towards supporting static builds of KDE software, starting with the frameworks. Various improvements, sheer amount of which by Alexander Lohnau, were made to plugin handling in kcoreaddons as well as in ECM. Notably, this work is already in use by KWin for its plugins handling.
I myself have been voluntarily maintaining ports for a subset of KF5 Frameworks in vcpkg, which by defaults offers only the static compilation on macOS and Linux. As a result, I reported or fixed — where my still limited knowledge of KF5 allowed — a bunch of issues within the frameworks themselves.
Most of these issue were of similar, trivial nature, and could easily be avoided at the time of code contribution by a CI job performing static compilation.
This task is to implement such static job and have it enabled for Tier1-3 frameworks, so that going forward, we limit the static compilation issues that make it to released code.
**An obvious question, at this point, is: why this effort?**
Static compilation brings several benefits, mostly in terms of binary packaging. This summary by Volker Krause is a good write-up on it: https://www.volkerkrause.eu/2018/10/13/kf5-static-builds.html
Almost all of the user-facing advantages are only to the benefit of self-contained distributables — i.e. not where software is collectively compiled against common set of libraries and distributed via package managers, e.g on Linux (apt, zipper) or macOS (Homebrew).
From a binary distribution perspective:
* it provides smaller self-contained binary distributables. Android, AppImage, macOS and Windows installers all are immediately benefited by that.
* this implies potentially much simplified distributable scripting
* less binaries = less moving parts, easier notarization, in case of macOS.
* potentially less-hackable/more-secure
* the runtime "symbol not found" issues are non-existent
From user perspective:
* where storage space is an issues, e.g. on Android, the installed software is smaller in size.
* statically complied applications launch substantially faster
* the in-memory code contains only the code actually used by the application or its dependencies, which will result in lower *maximum* memory resources consumed. The trade-off, though, is that *all* of that code is loaded at runtime. Depending on a use case, i.e. for apps that rely heavily on libraries and typically only use a small subset of them upon launch, this could be considered a disadvantage.
From CI perspective:
* linker is more thorough with symbol checking, as it traverses the whole dependency tree when building the binary file. This could in theory benefit the dynamically-compiled distributables as well, if they were built from the same set of dependencies as those in use by the CI static job.