Describe how to use it with MSVC

[KalitaAlexey]

Hello everyone.
I tried to find any information about coupling MSVC with sccache, but I failed.
It would be great to have a page describing how to setup it, debug it and etc.

[luser]

Hi there! sccache works very similarly to ccache, in that you simply take a compile commandline and prepend sccache to it, like:
cl.exe -c -Fotest.obj test.c
becomes: sccache.exe cl.exe -c -Fotest.obj test.c

How you would do this in a specific project's build system depends on the build system in use.

[KalitaAlexey]

@luser,
Have you used it with DevEnv or with Visual Studio?
This information can be helpful more than only for me.

[luser]

I have not, sorry! I don't know if it's even possible to make Visual Studio wrap compilations like that.

[KalitaAlexey]

I tried to find any information and I failed.
That's why I am asking about tutorial about setting sccache up for MSVC.

[KalitaAlexey]

I found some information about it.
Right now I am testing it.
I will open a PR if it works.

[kwaegel]

Thanks @KalitaAlexey. I'd be curious to see what you're trying out, even if it doesn't end up working.

Absent a better solution, we could implement a "stand-in" mode like cclash does, replacing cl.exe with the sccache binary and forwarding calls to a renamed version of the actual compiler (e.g. cl_real.exe). It's an ugly hack, but it should work with Visual Studio even when nothing else does.

I'd also suggest changing the docs to differentiate MSVC support from Visual Studio support, since that's likely to confuse people.

[luser]

Absent a better solution, we could implement a "stand-in" mode like cclash does, replacing cl.exe with the sccache binary and forwarding calls to a renamed version of the actual compiler (e.g. cl_real.exe). It's an ugly hack, but it should work with Visual Studio even when nothing else does.

sccache does support this already--if you copy the sccache.exe binary to cl.exe it will run as if you ran sccache.exe cl.exe, and use the next cl.exe available in your path.

I'd also suggest changing the docs to differentiate MSVC support from Visual Studio support, since that's likely to confuse people.

The docs currently say "Sccache (tries to) support gcc, clang and MSVC. If you don't specify otherwise, sccache will use a local disk cache." It's perhaps not incredibly clear. If you have a suggestion for making that clearer I'd be happy to take a PR to change it!

[kwaegel]

sccache does support this already--if you copy the sccache.exe binary to cl.exe it will run as if you ran sccache.exe cl.exe, and use the next cl.exe available in your path.

I'm not entirely sure how that would work, at least by default. If I understand the VS2017 instillation correctly, it installs four copies of cl.exe by default, none of which are added to the system path (x86, x64, x86_on_64, x64_on_86). Visual Studio calls these directly, not by searching the path. If you replace one of the cl.exe binaries with a renamed sccache.exe, it can't call the correct cl.exe because you've just replaced it.

cclash seems to get around the path problem by searching the current directory for a copy of the compiler that is not named cl.exe, to avoid naming conflicts. This is the hack I was referring to.

It might be possible to work around this for one of the four compilers by moving the real cl.exe to a subdirectory and adding that to the path, but I'm not sure what else that would break (e.g. the real compiler may be expecting to be in a certain directory).

If you have a suggestion for making that clearer I'd be happy to take a PR to change it!

Will do. :)

[TBBle]

An option might be to install a separate MSBuild toolset platform, which would also let you specify the command-line to be something other than cl.exe. You'd want one for each MSVC toolset and platform you want to support, and it would be set up to simply import the normal toolset platform for all the settings and then override the compiler executable path. I think you can override the executable name too, but I'm not certain.

An installer could generate these as well pretty easily, based on the currently-installed toolsets. You could also then offer sccache-specific options in the UI.
If it's not clear what I mean, it's dropping files in (for VS2010-VS2015 x64 target):

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\(V100|V110|V120|V140)\Platforms\x64\PlatformToolsets

or for VS2017 x64 target:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Platforms\x64\PlatformToolsets

Both Clang/C2 and Clang/LLVM (clang-cl) use this mechanism to insert their install dirs into the search path before the directory with MSVC cl.exe.

For CMake users, it's then the -T option at generation time. For direct Visual Studio users, there's a drop-down in the solution properties to select the desired toolset.

[kwaegel]

@TBBle That looks like the best solution, but I dug through the toolchain files and they're a bit of a nightmare, at least for someone who's never touched MSBuild scripting before. I'm finding plenty of documentation on using various toolchains, but nothing so far on writing a new one. Any ideas where to look?

It certainly seems like you can change the executable name, since VS is using clang at C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\ClangC2\14.10.25903\bin\*\clang.exe, with various c2.dll files added to the path depending on the target architecture. However, I haven't managed to find that string yet.

[TBBle]

Yeah, I had the same problem trying to work out how it selects 'clang.exe'. The Clang/C2 scripts are going to be hard to read because they're a full stand-alone toolchain, with their own configuration arguments and properties.

As a simpler example of redirection of the toolchain platform toolsets, see Clang/LLVM's scripts at https://github.com/llvm-mirror/llvm/tree/master/tools/msbuild. They stamp out a .props file for each platform toolset, which inherits from the native toolset and then changes the executable path to find clang-cl's cl.exe instead.

It also adds a command-line parameter since clang-cl needs to know the version of cl.exe which it is emulating.

The basic procedure is:

• for every platform toolset you want to wrap
  ** five MSBuild-based toolchains so far; v100, v110, v120, v140, v141; three platforms: Win32, x64 and ARM; three MS-provided variants: v1xx, v1xx_clang_c2 and v1xx_xp (not v100): 45 hits on the matrix, although not all of those exist or make sense to support here.
• create a new platform toolset which includes the relevant targets and props of the toolset you're wrapping, and then just override/extend the one or two properties needed (e.g. prepend to the executable path).
• Install sccache as cl.exe somewhere in prepended path directory using the existing argv[0] detection.
  ** If you can work out how to make MSVC use a different executable name, you can do that instead. (I'm sure Clang/LLVM's scripts would like that too. ^_^)
  ** Perhaps support for sccache.exe as clang.exe if not already present, to support both clang/c2 and non-MSBuild users of clang/LLVM (who also have a clang-cl.exe available if I recall correctly)

You could also do the same thing to wrap Clang/LLVM's platform toolsets if present.

---

As a less-intrusive approach, it might be possible to use the 'ImportAfter' directories to override any toolchain you like, but you lose the easy configuration of the toolchain selection.

[Orphis]

There are new possibilities now: https://blogs.msdn.microsoft.com/vcblog/2017/06/14/cmake-support-in-visual-studio-whats-new-in-2017-15-3-preview-2

Visual Studio 2017 supports CMake and the version 15.3 (right now in preview 2) supports Ninja as a generator. CMake supports a setting to prefix the compiler invocation with a command. You can then just set it to sccache and it will just work.

Sure, this isn't perfect as the CMake experience is a bit different from the regular msbuild project experience and it doesn't work with older versions of Visual Studio. But it works quite well and it could definitely be a solution moving forward!

[jasonwhite]

Here's a way to change the CL.exe tool path that MSBuild uses without messing with your Visual Studio installation:

msbuild blah.sln /m /p:Platform=x64 /p:Configuration=Debug /t:Rebuild ^
    /p:CLToolExe=cl.exe /p:CLToolPath=C:\tools

Where C:\tools contains cl.exe which is just the renamed sccache.exe.

Unfortunately, there are still more problems with using sccache with msbuild:

1. sccache doesn't handle response files (e.g., @blah.rsp). msbuild likes to use these behind the scenes.
2. sccache doesn't handle multiple source files on a single command line.
3. The sccache server must be started within a VS command prompt so it can find the dependent DLLs for cl.exe (e.g., mspdb140.dll). Alternatively, you can just fuddle with the PATH so it finds dependent DLLs correctly.

[luser]

sccache doesn't handle response files (e.g., @blah.rsp). msbuild likes to use these behind the scenes.

FYI we do have support for response files for gcc, we could probably expand that to work with MSVC as well.

sccache doesn't handle multiple source files on a single command line.

This would probably be kind of hard to shoehorn into sccache's current model, unless we split it up into one compile job per source file internally and then recombined the results at the end.

The sccache server must be started within a VS command prompt so it can find the dependent DLLs for cl.exe (e.g., mspdb140.dll). Alternatively, you can just fuddle with the PATH so it finds dependent DLLs correctly.

Yeah, this is a bit unfortunate. If you don't run the sccache server manually the first compile invocation will spawn a server which should have the right environment. We actually might be able to fix this, since we do pass the environment from the compiler invocation to the server for use for compilation--I'd guess the only thing that's breaking here is the few compiler invocations the server does to detect the compiler type and showIncludes prefix.

[jasonwhite]

FYI we do have support for response files for gcc, we could probably expand that to work with MSVC as well.

Cool. I'll take a shot at implementing this for MSVC.

sccache doesn't handle multiple source files on a single command line.

This would probably be kind of hard to shoehorn into sccache's current model, unless we split it up into one compile job per source file internally and then recombined the results at the end.

Maybe once I get more familiar with the code, I can take a shot at this too if such a change would be welcome. No promises though.