Closed YngveNPettersen closed 5 years ago
I'm not sure I understand: you can already specify the exact cl command line to invoke by setting the CLCACHE_CL
environment variable to point to some specific compiler executable and then passing all arguments on the command line, no? Can you maybe give an example of what you mean?
I mean "clcache path/to/cl.exe params"
I see - can you elaborate on when this would be useful? I'm not familiar with Chromium or Ninja really. What you describe seems to be equivalent to
set CLCACHE_CL=path/to/cl.exe
clcache params
on first glance. I suppose that's not sufficient for your use case?
It would be similar, but chromium specifically sets up a toolchain with all commands used by ninja, with fully qualified paths for the compiler and link executables. The GN code setting up the toolchain already have functionality to use ccache with the command path as the first positional argument, so it is easy to enable that functionality without having to change too much in the toolchain setup in our environment.
This also makes it easier to just flip the GN flag for enabling clcache for various product environments without having to perform "tricks" with the PATH variable.
@YngveNPettersen After re-reading, I wonder how this would work exactly. I suppose the idea is that if the first argument to clcache.py
is an existing file and that file ends in .exe
, then we assume it's the path to the real compiler? I suppose that could work - I'm trying to think of counter-examples, but couldn't find anything convincing.
One, somewhat far-fetched, case I could think of: if you try to compile and link a source file ending in .exe
, e.g. as in
cl foo.exe (or: clcache.py foo.exe)
Then you would get an error message about an invalid extension used for a source file. With the proposed semantics, the error message would differ in that we would print an error about not being able to execute the program 'foo.exe'.
@frerich I would also like this feature. We are already using ccache with cmake via the CMAKE_C_COMPILER_LAUNCHER option and having this feature would make it easier to use clcache just like ccache in our build system.
@frerich I found the hint in the caveats how to easily invoke MSBuild corret:
msbuild.exe /p:TrackFileAccess=false /p:CLToolExe=clcache.exe /p:CLToolPath=c:\path\to\the\clcache
So I am now just passing this parameters to MSBuild via cmake. Maybe this should also be added to the integration page.
@benjaminfuchs Great to hear that! I think an addition to the 'Integration' page would make a lot of sense -- I don't use msbuild
myself though, so I couldn't quite verify the information. Feel free to adjust the Wiki page with a section which you would have liked to see yourself. :-)
@frerich I added a MSBuild section to the Integration page what might have save me some time 👍
@benjaminfuchs Awesome, that's the spirit! :-) Thanks a lot!
This is a great feature! Ever since I learned about the CMake feature that allows specifying a launcher for the compiler via -DCMAKE_CXX_COMPILER_LAUNCHER
I wanted to make clcache compatible with it. Today I saw that it is already implemented and I had the time to try it out with one of my projects and it works like charm. To be able to use clcache now with CMake the only thing that needs to be done regarding integration of clcache into the toolchain is to specify -DCMAKE_CXX_COMPILER_LAUNCHER=clcache
and thats it. Nothing else, no .bat no Path changes.
I just needed to recognized that this is not in the released 4.2.0 version, but I just grabbed the App-Veyor artifact from the mr.
Thanks to all of you!
While having clcache map directly to cl might be useful for Visual Studio projects, in other cases, such as with the Chromium project which uses ninja project files generated by their GN system (and which have direct support for enabling ccache) being able to specify the actual cl command on the command line would be better, especially in environments where one is both compiling with clcache and withou clcache.