Use ccache in windows CI

[sylvlecl]

Goal

The goal is to implement compiler output caching for the windows CI, using ccache, to speed up the build.
See issue #1718.

Implementation
Followed the guidelines from https://github.com/ccache/ccache/wiki/MS-Visual-Studio :

• copy ccache.exe to cl.exe to "masquerade" the compiler
• set the necessary options for MSVC (using CLI variables instead of changing cmake files)

Had to remove hard-coded MSVC compiler option /Zi which asked for the generation of debug information, which is anyway not useful in CI.
In local environment, this will instead be added as necessary by cmake, depending on the type of build requested.

Result
Seems to work quite well, see job here:
https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions/runs/6731632879/job/18299509143

ccache stats
  D:\a\Antares_Simulator\Antares_Simulator\ccache\ccache.exe -s
  Cacheable calls:   754 / 754 (100.0%)
    Hits:            754 / 754 (100.0%)
      Direct:        754 / 754 (100.0%)
      Preprocessed:    0 / 754 ( 0.00%)
    Misses:            0 / 754 ( 0.00%)
  Local storage:
    Cache size (GB): 0.1 / 0.5 (20.31%)
    Hits:            754 / 754 (100.0%)
    Misses:            0 / 754 ( 0.00%)

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[JasonMarechal25]

Whouldn't ccache use and particularities on Windows be useful to figure in a ADR or at least some comments somewhere?

[JasonMarechal25]

Can't we use vcpkg to install ccache?

[sylvlecl]

I don't find it in vcpkg repo.
A possibility was to install it with chocolatey, like we do for wget/zip above, but it just makes it more difficult to implement the "masquerading" technique because choco will install it in it own nested folders, and we must take care of not using the shim executable that it creates.
Installs from choco also seem slower compared to the plain download from github relase.

[JasonMarechal25]

What's /zi option? Why is it removed?

[sylvlecl]

See explanation in the PR description:

Had to remove hard-coded MSVC compiler option /Zi which asked for the generation of debug information, which is anyway not useful in CI.
In local environment, this will instead be added as necessary by cmake, depending on the type of build requested.

So, actually this hard coded flag did not have anything to do here (actually the other ones would deserve to be questioned too, but it's not the scope of the PR).

[sylvlecl]

(ccache does not support this flag, probably because it has the effect of producing additional output files, not only compiled code)

[flomnes]

Had to remove hard-coded MSVC compiler option /Zi which asked for the generation of debug information, which is anyway not useful in CI.

Please keep in mind that common-settings.cmake is also used for local builds, for which debug info might be useful.

[sylvlecl]

Indeed, CMake knows how to handle this alone, when building configuration Debug or RelWithDebInfo.
Setting compiler-specific flags in cmake files should be avoided as much as possible.
The developer is responsible to use the configuration he needs, we should not add debug information for Release config.

[flomnes]

My concern is that by manually setting COMMON_MSVC_FLAGS, we might override what was generated by CMake from CMAKE_BUILD_TYPE.

A general discussion is outside of the scope of this PR.

But with this PR specifically, we don't want to lose debug info when CMAKE_BUILD_TYPE=Release/RelWithDebugInfo

[sylvlecl]

Whouldn't ccache use and particularities on Windows be useful to figure in a ADR or at least some comments somewhere?

Good question: I guess it does if we want to use it in local developer environment, but I am not sure it is really useful.
If we say it's really more a CI thing, the comment in the workflow linking to ccache wiki may be enough ?

[a-zakir]

build time = 4min15s instead of 15min+ that's awesome!
just few questions how does work the "masquerade" ? does it mean that msvc original compiler (cl.exe ) is never used?
what's happen when msvc is upgraded?
other solution might be the utilization of RULE_LAUNCH_COMPILE used by buildcache,

[sylvlecl]

just few questions how does work the "masquerade" ? does it mean that msvc original compiler (cl.exe ) is never used?
what's happen when msvc is upgraded?

To be honest I don't know how it works exactly ... clearly it's still the already present MSVC which is called in the end by ccache, so in some way the "fake" cl.exe knows where to find the "true" one, but I don't know how.

[sylvlecl]

other solution might be the utilization of RULE_LAUNCH_COMPILE used by buildcache,

I saw that using such variables (like the CMAKE_CXX_COMPILER_LAUNCHER we use for linux) might work, but it requires to use Ninja as the cmake target. I tried to turn it on without changing anything else, but the CI failed :( See that workflow
It could be interesting to push the investigation though.

[flomnes]

Suggested change

	key: windows
	key: windows-ccache

[sylvlecl]

The action already appends that to cache names (see in ubuntu workflow, we also use the OS name as a key)