support for gcc compiler options being a file via @file option

[andreparodi]

we are using a file to specify our compiler options to gcc via the @file option. I have tested a trivial compilation and as soon as I do this I see the stats counting this compile as Non-cacheable calls. I believe it's hitting the gcc.rs:109. What I find misleading the the comment in the previous line talking about using a response file.

any command line parameter starting with @ should be a file with the gcc options. Would be awesome to have support for that.

https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall-Options
@file
Read command-line options from file. The options read are inserted in place of the original @file option. If file does not exist, or cannot be read, then the option will be treated literally, and not removed.
Options in file are separated by whitespace. A whitespace character may be included in an option by surrounding the entire option in either single or double quotes. Any character (including a backslash) may be included by prefixing the character to be included with a backslash. The file may itself contain additional @file options; any such options will be processed recursively.

[andreparodi]

will try to submit a patch but need to get through introduction to rust first.

[luser]

@glandium and I chatted about this as we were reviewing the existing set of sccache issues. The right way to do this would be to replace the @file with its contents in the commandline for the purposes of generating the hash key, but keep it there for actually running the compiler.

[alexcrichton]

Looks like an LLVM build runs into this on MinGW as well. The CMake build system there passes arguments that look like:

@CMakeFiles/LLVMOption.dir/includes_CXX.rsp

and that causes sccache to fail to cache most compiles.

(just another data point)