{9AA40D43-2AF4-391C-BE32-E755F2A361D0}
Win32Proj
launch-cl.cmd
e:/path/to/project/build
...
```
although the full `*.vcxproj` will have some differences, such as:
but that is to be expected, I reckon, and what’s important is that `CLToolExe` and `CLToolPath` properties have the correct values.
However, trying to build this configuration will fail:
```cmd
> cmake --build . --target install --config Release -- /m
Building Custom Rule E:/path/to/project/CMakeLists.txt
E:\tools\vs\vs2022\MSBuild\Microsoft\VC\v170\Microsoft.Cpp.ClangCl.Common.targets(235,5): error : Building with "clang-cl.exe". [E:\path\to\project\build\thingy.vcxproj]
E:\tools\vs\vs2022\MSBuild\Microsoft\VC\v170\Microsoft.Cpp.ClangCl.Common.targets(235,5): error MSB6004: The specified task executable location "E:/path/to/project/build\clang-cl.exe" is invalid. [E:\path\to\project\build\thingy.vcxproj]
```
From that output I gather that this time MSBuild(?) ignored(?) the `CLToolExe` value from `*.vcxproj`, while still respecting the `CLToolPath` property from the same file, and that results in an invalid path `E:/path/to/project/build\clang-cl.exe` (_with a wrong slash?_), where `E:/path/to/project/build` is a correct value from the `CLToolPath` property, but `clang-cl.exe` is a wrong value, because instead there should be `launch-cl.cmd` value here from the `CLToolExe` property, shouldn’t it.
So far it looks like there is something wrong with MSBuild(?), as CMake generates a correct(?) project file, which does work fine without `-T ClangCL`, so it’s MSBuild who ignores `CLToolExe` property with this particular toolset and instead uses a hardcoded (_somewhere?_) `clang-cl.exe` value.
For now I’ve managed to find a workaround which is to simply provide `/p:CLToolExe` inline, and then MSBuild will finally respect it, and the build will go fine:
```cmd
> cmake --build . --target install --config Release -- /m /p:CLToolExe=launch-cl.cmd
```
Theoretically, one would also provide `/p:CLToolPath=e:/path/to/project/build`, but it is already present in `*.vcxproj`, and MSBuild does not ignore that one (_for some reason_).
I get the same results no matter what shell is used: it can be “plain” cmd, Git BASH or that special Visual Studio Developer Command Prompt / Developer PowerShell environment - makes no difference. So unless I have missed some more configuration parameters, this looks like a bug in MSBuild, because what else can CMake do to make it respect the `CLToolExe` property in the generated `*.vcxproj` file (_so one would not need to “enforce” it via inline CLI override_)? And once again, it all works fine with the “default” toolset (_so without `-T ClangCL`_).
If anything, I mostly use Ninja generator, so normally I wouldn’t care about something not working with VS generators, but unfortunately I do need to make this work with VS generators too.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [February 9, 2026, 3:44am UTC](https://discourse.cmake.org/t/using-ccache-with-visual-studio-generator-and-clangcl-toolset/15497/2 "2026-02-09T03:44:31Z")
Without knowing what CMake _should_ write, I would lean towards a Visual Studio issue. If you file one on their bug tracker, maybe they could provide information about what CMake could do about this.
---
### Author:  [@retif](https://discourse.cmake.org/u/retif)
#### Post date: [February 16, 2026, 11:06am UTC](https://discourse.cmake.org/t/using-ccache-with-visual-studio-generator-and-clangcl-toolset/15497/3 "2026-02-16T11:06:25Z")
I was going to do that, but did not want to jump through the hoops of creating a Microsoft account and fighting with their web-forms. Anyway, the problem is now reported [here](https://developercommunity.visualstudio.com/t/MSBuild-ignores-the-CLToolExe-value-from/11044817), so we’ll see how it goes.