I'm giving up there. Both Clang-cl and MinGW GCC report a far bigger
set of lines than their Linux / Mac counterparts (block ends, lines
containing just `else`, etc etc.), which wouldn't be a problem on its
own, if those lines would be covered. But on Windows there isn't a
single CI job that runs through GL/Vk codepaths -- as Mesa isn't easy to
get there and SwiftShader is utter crap -- which means there are extra
lines in GL/Vk codepaths that are reported as uncovered from Windows CI
jobs, while the same lines on Linux and Mac arere excluded and thus
there isn't anything that could make them green as well.
Not sure why this wasn't a problem in Corrade, maybe because here the
clang-cl build doesn't run GL tests and so while there the } lines were
marked by it as covered (instead of being ignored), here they're marked
as uncovered and all other jobs ignore them?
I kinda get the point, to avoid rogue third parties tainting my
ŕepositories with nasty backdoors, yes, but unless *everything* on the
way to the server including DNS queries is encrypted, then it's still
just a half of the solution and any silly corporate firewall can still
prevent me from cloning stuff from github dot com.
Took me a while (several years?) to figure out a way to benchmark this
without basically duplicating the testing effort and without new
variants being too hard to add.
Otherwise I'd need to duplicate that for clang-cl, mingw and so on. It's
enabled only on MSVC 2019 and newer, because I don'r really care about
older versions -- those are mainly for compatibility with existing code,
and Vulkan is not existing code yet.
This makes it possible to:
- finally use Magnum as a CMake subproject on Windows and have your
executables not fail to run with a "DLL missing" error (and the
setting is put to cache so superprojects just implicitly make use of
that)
- run tests on Windows without having to install first
- use dynamic plugins from a CMake subproject on any platform without
having to install first or load them by filename --- and the plugin
directory is now easily discovered as relative to
libraryLocation() of the library implementing given plugin interface
Three new builds (GL, GLES2, GLES3), Vulkan is now built with just MSVC
2019; removed 2015 RT builds because nobody cares and axed also GLES
2015 builds. In total it's one build less (well, the RT ones are
really slow, so way more than that in fact). Yay!