Feature Request: Have a build mode that leverages an XCBBuildService proxy for a more integrated experience

[brentleyjones]

We should support a new xcodeproj.build_mode value of "proxy", which causes Xcode to use a custom XCBBuildService proxy.

Differences from BwB mode (not all of this has to land in the initial version):

• BazelDependencies target only shows Bazel output, output from Bazel targets that don't translate to Xcode targets, and possibly output from unfocused targets
  • Probably will be renamed
• calculate_output_groups.py isn't needed any more
  • Similar functionality will be part of of the proxy, just loaded into memory
• BEP is parsed/translated to create a Build Report
  • Each target is represented as an actual target
  • Dia files are parsed and sent over as diagnotics (#400 and #402), fixing Fix-Its
  • Swift parsable output is parsed (when a new version of https://github.com/bazelbuild/rules_swift/pull/304 lands), showing per-file progress
  • Progress bar is updated to match the progress made towards the Build Report (so probably doesn't match Bazel's really weird progress indicator)
• Where possible, we no longer copy products to DerivedData (e.g. non-zipped binaries or bundles)
• If possible, IndexingInfoResponse points to bazel-out/ per-library indexing data, preventing the need for index-import
  • This can only work if -file-prefix-map is used

Some open questions:

• How do we want to integrate the proxy with Xcode? And do we make some of these options for the user to decide?
  • Launch Xcode.app/Contents/MacOS/Xcode from $SRCROOT with XCBBUILDSERVICE_PATH set. This has the side benefit of fixing some relative path issues (e.g. #1284). Ideally we could modify the name and/or icon of the Xcode instance in the Dock, otherwise this could be confusing (though we could kill all versions of the same Xcode that are open...).
  • Modify the Xcode.app bundle. This has permissions/security issues.
• Is this the new default?
  • I assume no, at least to start, and possibly ever, because of the above integration issues
• How are unfocused targets represented in the Build Report?
  • We might be able to give them an ID that isn't associated with a target in the project. If that's the case, they aren't handled any differently. Otherwise we can have them be sub-outputs on BazelDependencies

This issue will serve as an Epic. Smaller focused issues will be made as needed.

[thiagohmcruz]

Looks great at a high level! Some Qs/thoughts:

1. Are we planning to handle progress bar messages here as well?
2. +1 for initializing from $SRCROOT with XCBBUILDSERVICE_PATH set, unless there's a strong need / significant DX improvement for modifying the bundle I'd wouldn't go that route?
3. I think if this is going to be the default or not is something we can discuss once the impl is more mature? From a user perspective it would be nice to have the benefits of this mode by default I think but agree that we have to weight that vs the integration issues

[brentleyjones]

Are we planning to handle progress bar messages here as well?

I forgot to mention it. I’ve added it to the list above.