sccache places object file at different location compared to cl.exe and causes link failure when @rsp file is used

[UsernameLinde]

When the @rsp support pull request landed I was eager to use that on Windows/MSVC.

Context

The internal requirement was that the build process should be pretty much as is, changing to ninja from msbuild was not an option. So I first tried to hook in sccace in a clean way.
I use directory.build.props and a bat-file to get sccache prefixed before the call to cl.exe. More details here.

That worked: sccache gets to see the compile call, but I get Uncachable reason: multiple input files when the call is
d:\tools\sccache.exe cl.exe @C:\Users\me\AppData\Local\Temp\tmpfa7e185af63d4159b8ef0462dcbf1754.rsp

The rsp file do list multiple source files.

So I then changed the "compile call" to be python somescript.py %*, that is, I have a pythonscript which gets called with the rsp-file as parameter.

I parse the rsp-file. I group the conents into either "flag" or "source file".
Then for each source file:

• I create a new rsp-file with all the flags and then just that source name.
• I call sccache cl.exe @full_path_to_new_rsp_file.rsp

With this extra step, I can compile from visual studio. With rebuild I get cache hits. When it gets to linking, there is an error.

Actual problem

The rsp file contains /Fo"somename.dir\\Debug\\", so object files should go into a sub directory relative to the source location.
Assume that the rsp-file lists foo.c as file to compile.

When I use cl.exe @myrspfile.rsp I get somename.dir\Debug\foo.obj.
When I use sccache cl.exe @myrspfile.rsp I instead get somename.dir\Debug.obj

And this is the reason for link failure - /Fo can contain a directory name and does not have to be the filename for the output obj file.

[sylvestre]

@temportalflux rings a bell ? :)

[TBBle]

I note that the unit tests currently only test /Fo without a trailing slash.

The output path code is not handling the trailing slash case for /Fo, but I am only assuming this it the right place to fix it.

[temportalflux]

@temportalflux rings a bell ? :)

No, this issue doesn't ring a bell for me. I didn't deal with /Fo extensively in the MSVC RSP PR. Though the side node of struggles with multiple input files is quite familiar. It seems the case of /Fo containing trailing slashes is a good starting point for investigation for whoever tackles this bug.

[assarbad]

Same issue here, while investigating how to get MSBuild to "inject" sccache. You can see some progress on that front in #1830, which is my GitHub work account. I researched this in a private project first and got it to work now without explicit --start-server up front (for the "why", see #1830).

While this issue can be sidestepped by several means, one of the most pragmatic workarounds -- simply setting a full output file path -- would effectively suppress MSBuild batching (the process of combining the compilation of multiple translation units taking the exact same set of command line arguments into a single cl.exe invocation, for example).

I'll give it a shot and see if I can come up with a fix. But it may require some assistance from previous contributors as far as tests are concerned and possible other issues. Also, I'm just a budding Rustacean, not a seasoned one.

[assarbad]

@temportalflux any pointers regarding the multiple input files issue?

[temportalflux]

@temportalflux any pointers regarding the multiple input files issue?

Sorry, I don't have much to contribute here. I haven't touched sccache since my PR and even during the PR I was on the fringe of my area of expertise when it comes to MSBuild. I wish you the best of luck figuring this out though, wish I could give you better guidance.