It's clearly stated in the documentation that /Zi and /ZI are not supported as compilation flags. Nevertheless, it is not immediately clear to me why this must be so.
Use of /Zi and /ZI force the creation of a .pdb file during compilation. One contains Edit-and-Continue information, one doesn't.
Superficially, it seems to me that, instead of simply failing to run if these flags are specified (as they are in the vast majority of modern MSVC builds), clcache should run the normal compiler and cache both the .obj file(s) as well as the .pdb file. And that .pdb file can be associated with that particular list of .obj files.
Now the correspondence of .obj files to .pdb files is many to one. So clcache would also have to cache the list of source files that was provided on the command line, associate that list with the pdb file provided with /Fd on the command line, and save that .pdb file in cache.
Then, during later invocations of the same command line, if each of the files compiled on the command line ended up having their .obj files come out of the clcache, well we could just pull the corresponding .pdb file out of cache and restore it as well.
There may be a reason why this wouldn't work in practice, but I can't see a reason why it wouldn't work.
It's clearly stated in the documentation that /Zi and /ZI are not supported as compilation flags. Nevertheless, it is not immediately clear to me why this must be so.
Use of /Zi and /ZI force the creation of a .pdb file during compilation. One contains Edit-and-Continue information, one doesn't.
Superficially, it seems to me that, instead of simply failing to run if these flags are specified (as they are in the vast majority of modern MSVC builds), clcache should run the normal compiler and cache both the .obj file(s) as well as the .pdb file. And that .pdb file can be associated with that particular list of .obj files.
Now the correspondence of .obj files to .pdb files is many to one. So clcache would also have to cache the list of source files that was provided on the command line, associate that list with the pdb file provided with /Fd on the command line, and save that .pdb file in cache.
Then, during later invocations of the same command line, if each of the files compiled on the command line ended up having their .obj files come out of the clcache, well we could just pull the corresponding .pdb file out of cache and restore it as well.
There may be a reason why this wouldn't work in practice, but I can't see a reason why it wouldn't work.