Looking at the stats above, very few jobs misses and plenty of blob misses is a symptom of a small cache size. stashed knows about the compilation request (job hit) but cannot find the matching obj files (blob miss), most likely because they got removed from the cache.
Hi, I'm also testing stashed. looks really cool. A question:
There is an old problem compile problem with building in parallel (/MP) and using #import so we do not have /MP on some projects.
With stashed this problem started happening again. Does stashed build in parallel even if /MP is not on?
There is an old problem compile problem with building in parallel (/MP) and using #import so we do not have /MP on some projects.
With stashed this problem started happening again. Does stashed build in parallel even if /MP is not on?
I'm thinking that since I saw this:
"In this scenario, caching is disabled but compilation will still benefit from automatic multi-threading and the correct output will be generated."
here: https://github.com/playscale/stashed.io/wiki/Stats#job-unsupported
"In this scenario, caching is disabled but compilation will still benefit from automatic multi-threading and the correct output will be generated."
here: https://github.com/playscale/stashed.io/wiki/Stats#job-unsupported
stashed splits the command line in multiple compilation requests that are indeed run in parallel whether /MP is on or not
(googling the #import problem, we don't do anything special about it...)
looking at https://msdn.microsoft.com/en-us/library/bb385193.aspx it says that /MP is not compatible with #import, but I'd like to know why to understand how we can workaround that...
tis is a limitation in cl and I guess that modern code does not use #import anymore
there is also a workaround that Microsoft mention, to make a specific pass (target) that have the #imports and will generate the tlh and tli files, then in another pass (target) use the generated files.
so I would guess that stashed should not really have to do anything about this cl-flaw apart from maybe mention it and the workaround in the faq
There is a lot of stuff happening around #import, it can take many arguments on how to generate the tlh and tli files. I don't know if that matters to stashed though.
maybe stashed don't need to bother with all that. just identify it as "job unsupported" if #import is involved (through any header) and then have the workaround in the FAQ.
Thats pretty much what Microsoft do with cl /MP.
maybe stashed don't need to bother with all that. just identify it as "job unsupported" if #import is involved (through any header) and then have the workaround in the FAQ.
Thats pretty much what Microsoft do with cl /MP.
If stashed was to learn how to cache with #import and if pch is used then I suppose the easiest a workaround is to put the #import directives in the StdAfx.h and the other files could simply include the generated tlh files instead of using #import.
Since the pch has to be compiled before everything else, even when compiling in parallel, the tlh and tli files will be generated once only and can be used by the other compile units.
ie everyone has their workspace mapped to a common base path on a z: drive. But they are mapping from an arbitrary physical drive like c: or d:
I'm running into warnings when stashed.io is installed only on my machine, and I run a UE4 build distributed across multiple IncrediBuild agents. EXEC : warning : Stashed service could not be reached from this remote environment. Job hit:miss rate for consecutive full rebuild is around 1:3, probably due to this warning. All agents are Windows 10 with no special firewall settings that I know of.
I just installed stashed.io and it work possible because of my compiler flags. Here is the command I am using
cl file.cpp /MP /GS /TP /analyze- /W3 /Zc:wchar_t /I"Z:\F\dev\include" /I"C:\dev\vcpkg\installed\x86-windows\include" /Gm- /Od /Ob0 /Fd"proxy.dir\Debug\proxy.pdb" /Zc:inline /fp:precise /D "WIN32" /D "_WINDOWS" /D "BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE=1" /D "CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /Oy- /MD /std:c++17 /FC /Fa"Debug/" /EHsc /nologo /Fo"proxy.dir\Debug\" /Fp"proxy.dir\Debug\proxy.pch" /diagnostics:classic
I got it to work with a following the example in the docs i.e. cl /c /Yc a.cpp
Hi, I installed yesterday this product for evaluation. Coming from linux ccache (even distcc) I'm surprised to see it depends on the absolute paths (two working copies of the same code don't share cache results). I've read it's a restriction for distributed use, but is it also local?
I've seen (playscale/stashed.io#6) it's also local :-( OTOH, I'd say ccache does not depend on any environment variable), but (not sure, as I read about it long time ago) on the command line and a hash of the source files involved.
@Justin-Randall, in your update to #6 you mention the tradeoffs for relative path support and asked if "everyone [would] be OK with undefined debug behavior if the strange outcomes were well documented?". I imagine this would be acceptable to me, but also without relative path support almost all of the advantage of stashed would be lost for me. Could you go into what the kinds of strange outcomes might be? i.e. what the documentation might say.
Where possible, with the new feature, we will try to use relative paths. 3rd party libraries, system headers, etc... may be installed elsewhere, even if the content hash is identical. Currently Stashed chooses to treat that as a different hash (cache miss). If it did not, and your build retrieved some cache output built with different source locations, you may end up "missing" source files when debugging (as in, someone installed DirectX headers on their "F" drive, whereas you have them in a standard install location). The Visual Studio IDE will let you work around this manually, but it is probably not what most people would expect after building their changes and running under the debugger.
We really want Stashed to "just work" without much fuss, and where it would lead to different behavior, it should fall back to the compiler because "correct" is more important than "fast but incorrect".
In the case that the source is the same and only difference was its absolute location used for finding the source when debugging then I wouldn't consider the result to be incorrect. It isn't uncommon with prebuilt thrid party libraries to need to locate the source when debugging because it was located elsewhere on their build server. In my use case the system compiler and std library are in common locations and the application code and 3rd party libraries are located in slightly different directories both between users cmputers and betweent each of the copies of the repo on my own computer. So with relative path and content matching I would not only be able to get cache hits from other computers but also get more cache hits on my own computer.
Are the debug symbols for stashed.io releases available for download or on a symbol server somewhere?
The new debug generation flag Zf (used together with Zi,ZI), would that help to make stashed work with pdb files (Zi) also?
https://docs.microsoft.com/en-us/cpp/build/reference/zf?view=vs-2017
https://docs.microsoft.com/en-us/cpp/build/reference/zf?view=vs-2017
Another question, does anyone know if Z7 (C7) debug info is supposed to work with debugging coroutines?