User talk:Wrobelda

KDE static frameworks mail: libraries

All,

As some of you may have noticed, we’re moving towards supporting static builds of KDE software, starting with the frameworks.

The serious groundwork has been laid over past ~12 months with various improvements, sheer amount of which by Alexander Lohnau. These include improvements to plugin handling in kcoreaddons as well as in ECM.

I myself have been 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. Many of these issues are of similar nature, discussed below.

Now, few days ago static templates were added to GitLab that allow to enable static compilation and testing on Windows and Linux platforms: https://invent.kde.org/sysadmin/ci-utilities/-/merge_requests/35, with subsequent related commits in master.

What this currently does is it compiles the libraries with -DBUILD_SHARED_LIBS=OFF and stores the artifacts in a separate cache location — separate from the other, dynamically-compiling CI jobs. For now, that location was seeded with the same Craft-packaged dependency libraries as the dynamic artifacts location is. That means that, at this time, the Qt binaries used by the static CI jobs in speech are still built dynamically. Ultimately, the goal is to have all of these libraries — as long as possible — to be available as static builds. See the discussion in the MR linked above for the context.

Now, what that means for KDE contributors:

• library contributors, including but not limited to KF5 frameworks:

   * When working with the code, pay attention to the test suites. The static CI jobs in GitLab will make sure that your tests compile and pass when compiled statically.
   * When working with CMakeFiles.txt, any change to find_package() or any logic guarding such calls should be reflected in CMake.config.in file. This isn’t anything new, but what’s new is that you also need to capture all the PRIVATEly linked libraries as well. This is so that that any statically-compiled consumer of the library in speech can locate all of the dependencies, including the transitive ones.
       * While this seems obvious, please note that this applies to CMakeFiles.txt in all the subdirectories as well.
       * An example for the reference: https://invent.kde.org/frameworks/kio/-/blob/master/KF5KIOConfig.cmake.in#L23
       * Any issues regarding *CMake.conig.in will get reported only when consumed by another library
       * This is the most commonly reoccurring issue with static consumption of the libraries

• application contributors

   # Until the Tier1-3 KF5 libraries are made fully compatible with static-compilation and subsequently available as artifacts in CI/CD, there’s nothing you should do right now.

FAQ:

• Why?

 Static compilation brings several benefits, mostly in terms of binary packaging. For more context, see the brief discussion in the MR linked above. Also this summary by Volker Krause is a good write-up on it: https://www.volkerkrause.eu/2018/10/13/kf5-static-builds.html
 tl;dr:
   * smaller (on disk and in-memory), faster, self-contained binary distributables. Android, AppImage, macOS and Windows builds all are immediately benefited by that.
       * this implies potentially much simplified distributable scripting
   * less binaries = easier notarization, in case of macOS.
   * potentially less-hackable/more-secure
   * from CI perspective, linker is more thorough with symbol checking.
   * from dev perspective, with the aforementioned work by Alex Lohan, it's easy to in-place debug apps which use plugins, especially on macOS and Windows. See https://invent.kde.org/office/kmymoney/-/wikis/Compilation#static-vs-dynamic-linkage