With CI template for static Windows/Linux builds added, the next step is to enable those builds for Framework projects in their respective .gilab-ci.yml configs.

This has to follow the dependency tree, so that each Framework has its dependencies' static artifacts readily available in GitLab cache before its own build is enabled.

The goal of these jobs is to curb static compilation issues. Most of these issue, from the experience so far in fixing those, are of similar nature:

1. in CMakeFiles.txt, find_package() additions or changes, or any changes to logic guarding such calls, is often not mirrored with corresponding find_dependency() calls in CMake.config.in file. The necessity of such mirroring isn’t anything new, but what’s required for static compilation is that all of the PRIVATEly linked libraries need to have a find_dependency() added as well, within the if(NOT @BUILD_SHARED_LIBS@) block. This is so that that any statically-compiled consumer of the library in speech can locate all of the dependencies, including the transitive ones.
   • Examples of that in KDE codebase.
   • Any issues in library A's CMake.config.in will only get reported when consumed by another library (B). This imposes a problem, such that B library's CI jobs can start randomly fail after a code change in A's CMake.config.in. This is hardly something new, however, as this applies to shared linkage as well, and the fix is trivial.
2. in CMakeFiles.txt, implicit SHARED modifier added to add_library(), which takes precedence over the BUILD_SHARED_LIBS switch. Linkage should not be enforced. For reference, see: https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html
3. in unit tests, .qml plugin loading.

Note: the goal of this task is only to test for the static compilation and consumption, not the actual functionality of the libraries. Such improvements are to follow once the compilation is sorted out first.

Similarly, until the Tier1-3 KF5 libraries are made fully compatible with static-compilation and runtime issues get fixed, there’s nothing to be done from Application maintainer's perspective — that is unless they're willing to and their dependencies are already covered