Skip to content

List dependencies to build SourceKit-LSP in the Linux section #403

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 26, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions Documentation/Development.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,25 +38,25 @@ $ swift build

### Linux

Install the following dependencies of SourceKit-LSP:

* libsqlite3-dev, libncurses5-dev, python, ninja-build

```sh
$ export PATH="<path_to_swift_toolchain>/usr/bin:${PATH}"
$ swift package update
$ swift build -Xcxx -I<path_to_swift_toolchain>/usr/lib/swift -Xcxx -I<path_to_swift_toolchain>/usr/lib/swift/Block
```

Setting `PATH` as described above is important even if `<path_to_swift_toolchain>/usr/bin` is already in your `PATH` because `/usr/bin` must be the **first** path to search.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because /usr/bin must be the first path to search.

Why would it need to be first? Obviously if you have more than one toolchain on your path you need the right one to come before the wrong one, but that's just normal PATH behaviour.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that in the docker container, we have the following PATH:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

sourcekit-lsp finds libsourcekitdInProc and libIndexStore relative to /usr/sbin in /usr/sbin/../lib/ (aka. /usr/lib). Thus /usr/sbin is not discarded and it becomes the default toolchain. But it doesn’t contain the swift (or clang) executable, causing all sorts of later failures. If /usr/bin is before /usr/sbin in PATH, we don’t hit this issue.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, the note is fine for now, but this seems like something we should fix. We could recognize when one toolchain is a strict superset of another one (sbin and bin have the same libraries but only bin has the executables).


After building, the server will be located at `.build/debug/sourcekit-lsp`, or a similar path, if you passed any custom options to `swift build`. Editors will generally need to be provided with this path in order to run the newly built server - see [Editors](../Editors) for more information about configuration.

SourceKit-LSP is designed to build against the latest SwiftPM, so if you run into any issue make sure you have the most up-to-date dependencies by running `swift package update`.

### Docker

SourceKit-LSP should run out of the box using the [Swift official Docker images](https://swift.org/download/#docker). However, developers who wish to build `sourcekit-lsp` from source and to run its test suite will require additional packages to be installed.

* libsqlite3-dev, libncurses5-dev, python, ninja-build

These can be added to a custom Dockerfile that uses a Swift Docker tag for its base image.

Note that you still need to follow the steps listed in the *Linux* section. In the official docker images, the toolchain is located at `/`.
SourceKit-LSP should run out of the box using the [Swift official Docker images](https://swift.org/download/#docker). To build `sourcekit-lsp` from source and run its test suite, follow the steps in the *Linux* section. In the official docker images, the toolchain is located at `/`.

If you are seeing slow compile times, you will most likely need to increase the memory available to the Docker container.

Expand Down