Skip to content

MSVC CCache support

AnyOldName3 requested to merge AnyOldName3/openmw:sea-cache into master

Actual working CCache support for MSVC.

The caveat is that it's impossible to make it work with MSBuild/devenv.exe as they don't respect CMake's compiler launcher option and always use cl.exe directly.

It turned out that it already Just Worked for Ninja Release builds when elsid's new precompiled-header-disabling option was enabled. I just needed to wire up before_script.msvc.sh so it'd actually do that.

Enabling Debug and RelWithDebInfo builds just required switching from /Zi build-the-PDB-as-we-go debug symbols to /Z7 embedded debug symbols. It turns out that this wasn't as invasive as we previously thought - as long as the linker's got the /DEBUG flag it needed anyway, it'll strip the debug symbols out of the binary and create a PDB. However, the file size still ended up significantly bigger, and the internet says that the linker will refuse to do link-time optimisation (/LTCG) when it's doing this, so we need to remember not to use CCache for actual release builds, where we override the default Release configuration build flags to add /Zi (which would get turned into /Z7) and still want LTO.

Size comparisons:

thing size with /Z7 size with /Zi
openmw.exe 59,709,952 bytes 35,689,984 bytes
openmw.pdb 1,148,252,160 bytes 798,830,592 bytes

I've not switched over the CI to use Ninja instead of MSBuild. Part of the reason is the size difference, but mainly it's because I'm concerned that MSBuild is the most unique build system we support, so the most likely thing to break in MRs that change the CMake, so it's important that we actually run it. If we can figure out filtering jobs so they only run when CMake stuff and the prebuild scripts are altered by an MR, I'd be okay making it so only Ninja builds happen by default, but MSBuild jobs happen in push pipelines and in MRs affecting the relevant files. That would still end up saving us a lot of CI minutes overall.

Merge request reports