Normalize out `/[Ww]*` arguments

[refack]

They should not affect the binary + cache hits will omit them anyway

[frerich]

Hmm, this seems dubious to me; you're right in that warnings don't affect the object file, but they do affect the compiler output (which is also cached).

It would be great if you could add a test for this. In particular, I would expect that if you did

echo void f() { int x; } > foo.cpp
cl /c foo.cpp
cl /Wall /c foo.cpp

...then you would get no warnings printed on the first invocation, but you do get warnings printed on the second invocation (i.e. the two invocations are not equivalent since the compiler output differs).

[refack]

@frerich thanks for the answer. This is a pain point for me ATM, as I'm trying to re-align Node.js's warning exclusion list... It's quite frustrating that these two generate different hashes...

cl /wd4351 /wd4355 /c foo.cpp
cl /wd4355 /wd4351 /c foo.cpp

Would you consider a new ENV var? Something like CLCACHE_IGNORE_WARNINGS?

P.S. clcache has been a godsend it brings down build time on my machine from 2h to ~7m (we have a ton of de-optimizations, e.g. we recreate the proj/make/ninja files almost on each build)

[frerich]

@refack I agree that the two command lines you showed should be equivalent as far as caching goes. However, I'm not too fond with adding yet another configuration switch.

Instead of just ignoring warnings, how about clcache is adjusted to ensure that the order of the /wd arguments is always the same before computing a hash? E.g. by ordering them by the warning number?

[frerich]

By the way, it's great to hear that clcache is helping for you. Can you maybe elaborate a bit on the project you're working on? I'm always interested in hearing when people manage to get something out of the tool -- as a maintainer, you typically always only hear about the broken stuff but never about when things actually work. :-)