Implement/use the Build server protocol

[sideeffffect]

Consider implementing/using the Build server protocol

The problem this document aims to address is the multiplied effort required to integrate between available language servers/editors and build tools. Currently, every language server must implement a custom integration for each supported build tool in order to extract compilation information such as classpaths, source directories or compiler diagnostics. Likewise, new build tools are expected to integrate with all available IDEs. The growing number of language servers and build tools in the wider programming community means tooling developers spend a lot of time working on these integrations.
...
The Build Server Protocol has been designed to be language-agnostic. We're looking for ways to collaborate with other programming language communities and build tool authors.

(differences between LSP and BSP)

[jneira]

Afaik the ide would be a client of that build protocol, right?. It should be implemented in build tools like cabal or stack (or wrapping them)

[sideeffffect]

I could imagine a scenario, where a component of "ide" would wrap existing build tools (cabal, stack,... ) and pose as a build server, and other component(s) of "ide" would pose as build clients, happily talking to each other via the build server protocol

[hasufell]

Afaiu there's no reason that the BSP is implemented in the same tool as the LSP. Rather... HLS could be a user of a BSP server.

[michaelpj]

I think that would work badly for us, since we pretty heavily rely on having deep, in-memory access to the results of compilation. Pushing that across a protocol boundary would either be very slow or not fit into the protocol at all.

[hasufell]

I guess we can close as WONTFIX then?

[michaelpj]

Yeah, I guess. Maybe someone will do a deeper investigation and figure out that it is actually viable, but in that case we can reopen.