Cannot open compiler generated file: '"Debug\\".obj' with double backslash in the path

[frerich]

Cannot open compiler generated file: '"Debug\\".obj' with double backslash in the path

[dav-otero]

Do you need more information on this?

The way I have done it is basically:

• Renamed the Visual Studio cl.exe to cl_real.exe
• Rename dist/clcache.exe to cl.exe and put it in the Visual Studio folder.
• Set up CLCACHE_CL variable to

I have tried ccache to work in my cmake-based build system, but just leaving VS cl.exe as it is and passing the CMAKE variables CMAKE_C_COMPILER and CMAKE_CXX_COMPILER then cmake generation complains about not being able to find cl.exe. Here it is the gist of this problem:

https://gist.github.com/sowsem/2ad7da98fd225856fe9a90a233724318

This is extra information just in case there is some configuration problem in my clcache installation

[webmaster128]

Thanks for your feedback. An update of https://gist.github.com/sowsem/5080d43be4b32fea828a8f62cf8055ab from the current master would help because I improved tracing a bit.

---

To get around your cl.exe problem, try to set CC and CXX and do not touch CMAKE_C_COMPILER and CMAKE_CXX_COMPILER. This way you can keep the original cl.exe as it is.

E.g.:

set CC=C:\Users\kullo\clcache-webmaster128\dist\clcache.exe
set CXX=C:\Users\kullo\clcache-webmaster128\dist\clcache.exe
cmake [...]

Make sure to delete the entire build directory before re-running cmake.

[dav-otero]

I tried this before, but the result is always:

-- Configuring BuildId for target name: WindowsVS2013-Tests
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error in CMakeLists.txt:
No CMAKE_C_COMPILER could be found.

CMake Error in CMakeLists.txt:
No CMAKE_CXX_COMPILER could be found.

[dav-otero]

With the latest master I think I am getting the same output;
https://gist.github.com/sowsem/edd06cbcfb132296e16eb777817cea1f

BTW, If I execute manually the line where it says:

ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /nologo /W0 /WX- /Od /Oy- /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"Debug" /Fd"Debug\vc120.pdb" /Gd /TP /analyze- /errorReport:queue CMakeCXXCompilerId.cpp

It works and result code is 0.

[webmaster128]

Could you verify if #116 does the job for you?

[webmaster128]

Where does cmake get the output directory Debug\\ (double backslash) from? Is this a cmake default or somehow set by you?

[dav-otero]

Not sure if it is a cmake default. I am using cmake as the main build system, but it is used with mulitple macros in order to build for muliple platforms. I can investigate where it comes from, but the main point is that in the end the real compiler accepts this kind of input, but looks like clcache is not able to forward this input correctly into the real compiler. IMHO, clcache should support the same input as the real compiler does, right?

[dav-otero]

Love you guys! Current master is working for me! I will share this in my company and most likely start using this asap!
One missing bit is supporting \Zi, but you have already an issue related to this!

[frerich]

Great, thanks for letting us know @sowsem ! Indeed, support for caching (and restoring) .pdb files generated via the /Zi switch is tracked by issue #30 .

[dav-otero]

Hi again! I don't know which is this is the best place.

After the fix, compling from cmake in Windows actually works quite well and there are lots of cache hits for recompilations.
The tricky thing is that if instead I generate the VS solution and then compile. Then I remove the solution and generate it back again and try to build the solution again from VS, I always get cache misses.

Sounds familiar?

[dav-otero]

Another case: If I compile with the cmake, then delete the project and recompile with cmake, there are lots of cache hits.
If now I delete the project and generate the visual studio solution, open it and build solution, I get 0 cache hits, all cache misses.

[webmaster128]

Please open a separate issue for this

[frerich]

@sowsem I think this sounds like it's worth a separate ticket. I have some ideas on how to trace down the cause of this, but I don't want to hijack this ticket.

[dav-otero]

sure!

[dav-otero]

#135