use sccache on Windows

[Be-ing]

No description provided.

[Be-ing]

Still not working after #3589...

[Be-ing]

Well this is strange. Commenting out the /fp:fast compiler flag gets rid of the parse_arguments: CannotCache(multiple input files) error from the sccache server, but now it fails with

..\lib\googletest-1.10.x\googletest\src\gtest-all.cc: fatal error C1041: cannot open program database 'D:\a\mixxx\mixxx\build\bin\gmock_main.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS
cl : Command line warning D9025 : overriding '/Z7' with '/Zi'

But /FS is used and there is no /Zi used?

[Be-ing]

Google Test sets the Zi compiler option which is incompatible with Z7 and breaks the build. I submitted a pull request upstream to fix that.

[Holzhaus]

Maybe it's time to switch to doctest.

[Be-ing]

Requiring a tiny change to Google Test is IMO not a good reason to spend the effort switching away from it. But I am pretty wary of relying on Goolge-maintained software...

[Be-ing]

That brings the total Windows job time from 35 minutes to 19 minutes.

Using Ninja from the GH Actions VM image instead of downloading it from Chocolatey reduced the job time another 1.5-2 minutes, so now Windows jobs take 16-17 minutes. 🚀 Now, if GitHub Actions would get zstd working with caching on Windows...

[daschuer]

What was the reason for switching from clcache to cscache? Maybe clcache did not work for another reason that is fixed now as well.
I am asking because of relying on a patched version of sccache is not optimal.

Is cmake able to verify if the sccache is patched?

Is the PDB debugging still possible? It was originsl broken with /Zi, but I have read somwher that Microsoft has fixed it.

Please verify if this fix already works for us.

[Be-ing]

clcache is abandoned. Maybe it would work with the changes in this branch, but relying on unmaintained software is a bad idea. As far as I can tell, sccache is the only currently maintained compiler cache for MSVC.

I double checked and the mixxx.pdb file is still generated and installed with /Z7.

[Be-ing]

Is cmake able to verify if the sccache is patched?

No, but the build still works with the unpatched sccache. It just doesn't cache.

[daschuer]

If clcache just works for us, there is no need for active development. I would prefer to use this, because it will introduce less hassle to a new contributor, compared to use a patched version of cscache. It is even more bad if users believe to use it, but waiting ages anyway because of the bug.

[Be-ing]

Installing the patched sccache is no harder than clcache. Once the user has Rust installed, it is just:

cargo install --git https://github.com/Be-ing/sccache.git --branch fix_msvc_fp

and cargo does the rest. On GitHub Actions, building sccache takes 10 minutes the first time, then it is cached. This is practically the same as clcache, which also requires installing a language toolchain (Python) and running python -m pip install git+https://github.com/frerich/clcache.git

If clcache just works for us

But it doesn't, we don't know why, and I'm not wasting my time figuring out why unmaintained software doesn't work. I have already spent multiple days getting sccache working.

[Be-ing]

All that will change when my PR for sccache is merged is the cargo command:

cargo install sccache

[Be-ing]

I am opposed to adding dependencies on unmaintained tools when there is a currently maintained alternative which is used by large projects (Firefox and Rustc).

[Be-ing]

Merge?

[uklotzde]

Thanks for pushing this even further! LGTM

[daschuer]

We have now a 9m 29s penalty for build sccache from source.
I think we should fetch a pre build binary once the patch is merged.

[Holzhaus]

We have now a 9m 29s penalty for build sccache from source.
I think we should fetch a pre build binary once the patch is merged.

https://github.com/actions/cache/blob/master/examples.md#rust---cargo

[Be-ing]

The sccache build is already cached. GH Actions separates caches by branch so it may need to be rebuilt for the initial merge. But now it should take < 1 minute to restore from the cache.

Using the hash of the Cargo.lock file would be a good idea. Currently the key is just the commit hash of sccache Git repository. Of course that won't scale when we use cargo for more binaries such as Aoide.