This is a meta task to track the progress in bringing the Framework libs to compatibility with static compilation and consumption

As some of you may have noticed, for a while there's been a greenfield effort moving towards supporting static builds of KDE software, starting with the frameworks — or at least a subset of them, where it makes sense and is a low-hanging fruit.

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 @alex — were made to plugin handling in kcoreaddons as well as in ECM, which builds upon existing support for static plugins in Qt. Notably, this work is already in use by KWin and KMyMoney for their plugin handling, improving the launchtime, as well as enabling the in-place debugging (see e.g. https://invent.kde.org/office/kmymoney/-/wikis/Debugging#debugging-in-place-uninstalled)

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, zypper, etc.) 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 (smaller attack surface).
• the runtime "symbol not found" issues are non-existent.

A good write-up on Qt statically-vs-dynamically compiled apps with benchmarking can be read here: https://decovar.dev/blog/2018/02/17/build-qt-statically/

From user perspective:

• where storage space is a concern, e.g. on Android, the installed software is smaller in size.
  • TODO: add figures using KMyMoney AppImage and macOS Bundle
• statically complied applications launch substantially faster
  • this is especially pronounced with AppImage, which is effectively a fuse-enabled compressed filesystem, mounted dynamically at application runtime. Not only is that process slow, but loading of the plugins and libraries themselves is naturally slow as well. Reducing the number of files to a minimum significantly speeds up AppImage launch time.
  • TODO: add figures using KMyMoney AppImage
• 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.
  • TODO: add figures using KMyMoney AppImage and macOS Bundle

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.

All this effort supports current KDE goals: KDE Eco - Building Energy-Efficient Free Software and All About the Apps, particularly the recently announced effort to bring more apps to App Stores .

Disadvantages:

• added CI strain, running extra -static versions of existing CI jobs
• some development and maintenance overhead, see discussion in: https://phabricator.kde.org/T15837 . Do note, however, that these tasks do not actually introduce anything particularly new that wasn't in place already: plenty of the frameworks already support static consumption in their Config.cmake. At this point, the CI jobs are meant to secure that work in and prevent regressions stemming from discrepancies between the find_dependency() and find_package() calls in Config.cmake and the frequently updated CMakeLists.txt, respectively.

Finally, the scope of this task is not to make all the Frameworks fully compatible with static consumption, nor all of the Applications. At this point, we're looking at enabling simple use cases, where Applications do not use advanced kioslaves/KParts functionality. Work required to — eventually — get the latter done is do be discussed here: https://phabricator.kde.org/T15843