SourceKit-LSP for other build systems

[blangmuir (Ben Langmuir)]

Hey, thanks for the feedback!

@jvican

As a small extension, we could add a request that piggy-backs on the target (and would be updated using buildTarget/didChange notifications).

• buildTarget/outputPaths

Out of curiosity, what is this endpoint needed for?

I believe you could encode this information as a JSON object in the data field of the build target. In the Scala extension, we have an object called ScalaBuildTarget which enriches the build target information to provide Scala-specific data.. It sounds like this would be a good fit for this endpoint too.

We use the output paths as keys for determining if index data should be considered "visible". We have a one-to-one mapping between output paths and visible index data. The reason we didn't include this in the target itself is that we expect it to be non-trivial to compute and/or keep up to date. We didn't want to block getting targets on this.

@jvican

tell clients that some features are not supported by the server and vice versa with BuildClientCapabilities .

This seems reasonable to me, particularly once we've settled more on exactly what we need from the protocol.

@jvican

BTW, when the dust settles and the exploratory phase is over, I encourage you to upstream some of the stuff you've worked on to build-server-protocol/build-server-protocol . We could merge this work under a Swift extension and make the necessary changes to the base protocol.

Thanks, we'll keep it in mind!

[mackoj (Jeffrey Macko)]

Hi, @blangmuir

Maybe if you want to influence BSP now it's a good time because they are working on the v2.0.0 of the protocol.

LSP is working on LSIF that could help on Indexing(if I understand it correctly).

[atyshka (Alex Tyshka)]

Any updates on this? Working on a CMake-based swift project and really missing the convenience of sourcekit-lsp.