**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.
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. Notably, this work is already in use by KWin and KMyMoney for its plugins handling. That work already has an added benefit of speeding up the launchtime, as well as 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, 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
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 an issues, e.g. on Android, the installed software is smaller in size.
* 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 minimum significantly speeds up Application 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.
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 with current KDE goals: [[ https://eco.kde.org | KDE Eco - Building Energy-Efficient Free Software ]] and [[ https://community.kde.org/Goals/All_about_the_Apps | All About the Apps ]], particularly the recently [[ https://mail.kde.org/pipermail/kde-community/2022q3/007274.html | announced ]] effort to bring more apps to App Stores **.
**Disadvantages**:
* added CI strain, running extra `-static` versions of existing CI jobs
* development overhead, see discussion in: https://phabricator.kde.org/T15837