C++ dependency pruning is broken for remote execution on Windows

[buchgr]

When using remote execution in Windows Bazel will fail with an error of the type

undeclared inclusion(s) in rule  "@foo//:bar" this rule is missing dependency declarations for the following files included by "external/foo/bar.cc".
  'C:/bot/w/external/foo/bar.h'
  ...

This is because the dependency pruning code [1] scanning the /showParams output makes the incorrect assumption that source and generated files have a parent folder named 'execroot'. The assumption only holds for local execution without sandboxing. However, in remote execution we can't make any assumptions about the absolute location of files. Bazel doesn't know under which directory path an action is executed on a remote system.

[1] https://osscs.corp.google.com/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/rules/cpp/ShowIncludesFilter.java;l=151;drc=0b081d8593d9eeb4e31aceed0b066ce4482ece49

Related #6931

[coeuvre]

To support compiling c++ on windows remotely, execution services must do a hack which they need to replace the paths of the lines matched pattern Note: including file: <absolute path> with relative paths (relative to action working directory) in stdout of cl.exe actions.

For example, Note: including file: C:/bot/w/external/foo/bar.h should be replaced with Note: including file: external/foo/bar.h.

I had a discussion with @meteorcloudy, and below are the options we came up to fix this:

1. The easiest way is let cl.exe output relative header path, but MSVC doesn't support this option yet.
2. Having a wrapper script which print cwd to stdout and then execute cl.exe so when we parse the stdout of the action, we know which working directory it was executed remotely in. However, this may have 10%-20% performance impact.
3. Use parent directory of local execroot as input root, use execroot as working directory. So we can make sure folder execroot is included in the absolute paths.

/cc @lberki

[jan11011977]

Hi I noticed that this issue has been open for a while. I'd like to propose another solution:

I understand that this include validation is needed on Windows because we don't have a sandbox. However running with remote execution effectively functions as a sandbox, so arguably this include validation isn't needed when running remotely. If the remote compile is successful, that proves that all the required include files were declared correctly.

Would there be a way to disable the validation on the client side (if it's possible to detect that the compile was executed remotely there), or if that's not possible, it could be done on the remote execution side either by removing the output of /showIncludes, or possibly by removing the /showIncludes flag altogether.

My knowledge of Bazel is limited so apologies if I have misunderstood the problem.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!