You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 4, 2020. It is now read-only.
I do believe that clcache is working, verified by much faster build times as well as clcache -s showing changes.... however, within Visual Studio (with CMake), every build performs a full clean rebuild, which is faster due to clcache, but really CMake and MSBuild should realise things are up to date before that... and instead of a 3 minute build... i should get a 10 second "everything is up to date"
Any suggestions?
The text was updated successfully, but these errors were encountered:
@Cascades It almost finished, except that it use ProcessPoolExecutor, it is necessary only with v120 toolchain (MSVS 2013), would be better to switch back to ThreadPoolExecutor if v140 toolchain used. I have no idea how to do it properly (check FileTracker.dll or cl.exe version?..). Anyway ProcessPoolExecutor should work, but looks like it more often cause problem with stats.txt access denied than ThreadPoolExecutor (#339).
Codecov fails on lines 156, 160 due to wrong order of initialization coverage module and clcache (clcache.pth force to load clcache first). Lines 128-131 is specific for build environment.
As suggested in #273 and #355 I currently have this for my clcache in cmake in VS:
I do believe that clcache is working, verified by much faster build times as well as
clcache -s
showing changes.... however, within Visual Studio (with CMake), every build performs a full clean rebuild, which is faster due to clcache, but really CMake and MSBuild should realise things are up to date before that... and instead of a 3 minute build... i should get a 10 second "everything is up to date"Any suggestions?
The text was updated successfully, but these errors were encountered: