Integrating with Build Event Protocol

[sean7218]

Context

The sourcekit-lsp needs a set of compiler flags from bazel build server for background indexing and semantic analysis. Currently build server runs bazel action query to get target information and its compiler flags. However these queried actions have placeholder values and often doesn’t represent the final action being run. Especially for larger projects where transitions or config drifting can alter the final build action.

Proposed Solution

Build Event Protocol can be leveraged to get the final build action where swiftmodule paths are already resolved.

Action query can still be used as the entry point and BEP can be seen as supplementary or validating add-on. The final solution depends on which is more robust and performant

Questions

1. Do we want to use BEP and integrate it with build server ?
2. Do we want this to be an opt-in behavior or a default experience for user?
3. Do we want to make two modes, ActionQueryMode only or BEPMode only so user can switch to one or the other?

[tinder-maxwellelliott]

For 1 I think BES server is best. This process could be directly engaged via a GRPC from the BSP. We would need to support proxying events though as companies do use BES for other things

I'd opt for default. It's more performant and has no hangs or interrupts from additional Bazel calls

Ideally this configuration just needs the GRPC location to ask for data from, if that's not set then it falls through to existing Bazel calls. I think it would be ideal if we provided everything needed including a BES to provide the best experience possible. Buildbuddy has some excellent prior art here that I am familiar with but requires a go toolchain to run

[rockbruno]

Concept sounds good, can you share more info on how that works tool-wise? I'm familiar with BuildBuddy but not with what commands we would add to each places and so on