You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The term *build system* predated our wide-spread adoption of BSP for communicating between SourceKit-LSP to the build system and was never really the correct term anyway – ie. a `JSONCompilationDatabaseBuildSystem` never really sounded right. We now have a correct term for the communication layer between SourceKit-LSP: A build server. Rename most occurrences of *build system* to *build server* to reflect this. There are unfortunately a couple lingering instances of *build system* that we can’t change, most notably: `fallbackBuildSystem` in the config file, the `workspace/waitForBuildSystemUpdates` BSP extension request and the `synchronize-for-build-system-updates` experimental feature.
Notification sent from SourceKit-LSP to the build system to indicate that files within the project have been modified.
175
+
Notification sent from SourceKit-LSP to the build server to indicate that files within the project have been modified.
176
176
177
177
SourceKit-LSP may send file change notifications for a superset of the files that the BSP server requested to watch in `watchers`. It is the BSP server’s responsibility to filter the file watch notifications for the ones it is actually interested in.
178
178
@@ -182,6 +182,6 @@ Definition is the same as in LSP.
182
182
183
183
This request is a no-op and doesn't have any effects.
184
184
185
-
If the build system is currently updating the build graph, this request should return after those updates have finished processing.
185
+
If the build server is currently updating the build graph, this request should return after those updates have finished processing.
Copy file name to clipboardExpand all lines: Contributor Documentation/Background Indexing.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,9 +12,9 @@ Preparation of a target should perform the minimal amount of work to build all `
12
12
13
13
### Status tracking
14
14
15
-
When SourceKit-LSP is launched, all targets are considered to be out-of-date. This needs to be done because source files might have changed since SourceKit-LSP was last started – if the module wasn’t modified since the last SourceKit-LSP launch, we re-prepare the target and rely on the build system to produce a fast null build.
15
+
When SourceKit-LSP is launched, all targets are considered to be out-of-date. This needs to be done because source files might have changed since SourceKit-LSP was last started – if the module wasn’t modified since the last SourceKit-LSP launch, we re-prepare the target and rely on the build server to produce a fast null build.
16
16
17
-
After we have prepared a target, we mark it as being up-to-date in `SemanticIndexManager.preparationUpToDateTracker`. That way we don’t need to invoke the build system every time we want to perform semantic functionality of a source file, which saves us the time of a null build (which can hundreds of milliseconds for SwiftPM). If a source file is changed (as noted through file watching), all of its target’s dependencies are marked as out-of-date. Note that the target that the source file belongs to is not marked as out-of-date – preparation of a target builds all dependencies but does not need to build the target’s module itself. The next operation that requires the target to be prepared will trigger a preparation job.
17
+
After we have prepared a target, we mark it as being up-to-date in `SemanticIndexManager.preparationUpToDateTracker`. That way we don’t need to invoke the build server every time we want to perform semantic functionality of a source file, which saves us the time of a null build (which can hundreds of milliseconds for SwiftPM). If a source file is changed (as noted through file watching), all of its target’s dependencies are marked as out-of-date. Note that the target that the source file belongs to is not marked as out-of-date – preparation of a target builds all dependencies but does not need to build the target’s module itself. The next operation that requires the target to be prepared will trigger a preparation job.
18
18
19
19
## Updating the index store
20
20
Collapse file: Contributor Documentation/Implementing a BSP server.md
Copy file name to clipboardExpand all lines: Contributor Documentation/Implementing a BSP server.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,7 @@ If the build system loads the entire build graph during initialization, it may i
29
29
30
30
## Supporting background indexing
31
31
32
-
To support background indexing, the build system must set `data.prepareProvider: true` in the `build/initialize` response and implement the `buildTarget/prepare` method. The compiler options used to prepare a target should match those sent for `textDocument/sourceKitOptions` in order to avoid mismatches when loading modules.
32
+
To support background indexing, the build server must set `data.prepareProvider: true` in the `build/initialize` response and implement the `buildTarget/prepare` method. The compiler options used to prepare a target should match those sent for `textDocument/sourceKitOptions` in order to avoid mismatches when loading modules.
Copy file name to clipboardExpand all lines: Contributor Documentation/Modules.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,9 +6,9 @@ The SourceKit-LSP package contains the following non-testing modules.
6
6
7
7
Swift types to represent the [Build Server Protocol (BSP) specification](https://build-server-protocol.github.io/docs/specification). These types should also be usable when implementing a BSP client and thus this module should not have any dependencies other than the LanguageServerProtocol module, with which it shares some types.
8
8
9
-
### BuildSystemIntegration
9
+
### BuildServerIntegration
10
10
11
-
Defines the queries SourceKit-LSP can ask of a build system, like getting compiler arguments for a file, finding a target’s dependencies or preparing a target.
11
+
Defines the queries SourceKit-LSP can ask of a build server, like getting compiler arguments for a file, finding a target’s dependencies or preparing a target.
Copy file name to clipboardExpand all lines: Contributor Documentation/Overview.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,12 +18,12 @@ For requests that require knowledge about the project’s index, like call hiera
18
18
19
19
[sourcekitd](https://github.com/apple/swift/tree/main/tools/SourceKit) is implemented in the Swift compiler’s repository and uses the Swift compiler’s understanding of Swift code to provide semantic functionality. On macOS, sourcekitd is run as an XPC service and all other platforms sourcekitd is run in the sourcekit-lsp process. This means that on macOS, a crash of sourcekitd can be recovered by re-launching sourcekitd, while on other platforms a crash inside sourcekitd crashes sourcekit-lsp.
20
20
21
-
## Build systems
21
+
## Build servers
22
22
23
-
Basically all semantic functionality requires knowledge about how a file is being built (like module search paths to be able to resolve `import` statements). SourceKit-LSP consults a `BuildSystem`to get this information. Note that the term build system has a somewhat loose definition in SourceKit-LSP. It’s less about building the project and more about providing information that would be used if building the project. Build systems that are currently supported are:
24
-
-`SwiftPMBuildSystem`: Reads a `Package.swift` at the project’s root
25
-
-`CompilationDatabaseBuildSystem`: Reads a `compile_commands.json` file to provide build settings for files. `compile_commands.json` can eg. be generated by CMake.
26
-
-`BuildServerBuildSystem`: Launches an external build server process to provide build settings.
23
+
Basically all semantic functionality requires knowledge about how a file is being built (like module search paths to be able to resolve `import` statements). SourceKit-LSP consults a *build server*to get this information. Build servers that are currently supported are:
24
+
-`SwiftPMBuildServer`: Reads a `Package.swift` at the project’s root
25
+
-`CompilationDatabaseBuildServer`: Reads a `compile_commands.json` file to provide build settings for files. `compile_commands.json` can eg. be generated by CMake.
26
+
-`ExternalBuildServerAdapter`: Launches an external BSP server process to provide build settings.
Copy file name to clipboardExpand all lines: Documentation/Configuration File.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -30,12 +30,12 @@ The structure of the file is currently not guaranteed to be stable. Options may
30
30
-`disableSandbox: boolean`: Disables running subprocesses from SwiftPM in a sandbox. Equivalent to SwiftPM's `--disable-sandbox` option. Useful when running `sourcekit-lsp` in a sandbox because nested sandboxes are not supported.
31
31
-`compilationDatabase`: Dictionary with the following keys, defining options for workspaces with a compilation database.
32
32
-`searchPaths: string[]`: Additional paths to search for a compilation database, relative to a workspace root.
33
-
-`fallbackBuildSystem`: Dictionary with the following keys, defining options for files that aren't managed by any build system.
33
+
-`fallbackBuildSystem`: Dictionary with the following keys, defining options for files that aren't managed by any build server.
34
34
-`cCompilerFlags: string[]`: Extra arguments passed to the compiler for C files.
35
35
-`cxxCompilerFlags: string[]`: Extra arguments passed to the compiler for C++ files.
36
36
-`swiftCompilerFlags: string[]`: Extra arguments passed to the compiler for Swift files.
37
37
-`sdk: string`: The SDK to use for fallback arguments. Default is to infer the SDK using `xcrun`.
38
-
-`buildSettingsTimeout: integer`: Number of milliseconds to wait for build settings from the build system before using fallback build settings.
38
+
-`buildSettingsTimeout: integer`: Number of milliseconds to wait for build settings from the build server before using fallback build settings.
39
39
-`clangdOptions: string[]`: Extra command line arguments passed to `clangd` when launching it.
40
40
-`index`: Options related to indexing.
41
41
-`indexPrefixMap: [string: string]`: Path remappings for remapping index data for local use.
0 commit comments