Visual Studio IDE w/ CMake w/ clcache always rebuilds

[Cascades]

As suggested in #273 and #355 I currently have this for my clcache in cmake in VS:

function(any_target_hook)
set(NON_COMPILE_TARGETS INTERFACE IMPORTED UNKNOWN ALIAS)
  list(FIND NON_COMPILE_TARGETS ${func_ARGV1} found)
  if(${found} GREATER -1)
    return()
  endif()

  set_target_properties(${func_ARGV0} PROPERTIES VS_GLOBAL_CLToolExe ${variable_stoing_my_clcache_executable_name})
  set_target_properties(${func_ARGV0} PROPERTIES VS_GLOBAL_CLToolPath ${variable_stoing_my_clcache_path})
  set_target_properties(${func_ARGV0} PROPERTIES VS_GLOBAL_NoDependency $ENV{CLCACHE_DIR}/stats.txt)
  set_target_properties(${func_ARGV0} PROPERTIES VS_GLOBAL_TrackFileAccess "false")

endfunction()

function(add_library)
  _add_library(${func_ARGN})
  any_target_hook(${func_ARGN})
endfunction()

function(add_executable)
  _add_executable(${ARGN})
  any_target_hook(${ARGN})
endfunction()

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?

[izmmisha]

you can try this https://github.com/frerich/clcache/pull/319, it also solves stats.txt problem.

[Cascades]

@izmmisha Thought it would be a pain to do it with a rebase, so have force pushed the changes to bring it up to date, but with a commit on top

[izmmisha]

@Cascades thanks for your PR, https://github.com/frerich/clcache/pull/319 updated.

[Cascades]

@izmmisha Cool, thanks. Codecov failed but I may try and fix that today if I have time... Is the logic of your changes done or do you have more work?

[izmmisha]

@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 (https://github.com/frerich/clcache/issues/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.