[swift-dev] Automatically building SourceKit on Linux

Alex Blewitt alblue at apple.com
Tue Nov 22 12:05:37 CST 2016

I have created a few pull requests regarding SourceKit support on Linux:

https://github.com/apple/swift/pull/5861 <https://github.com/apple/swift/pull/5861> - Update documentation for building on Linux
https://github.com/apple/swift/pull/5862 <https://github.com/apple/swift/pull/5862> - Allow SourceKit to be built without errors on Linux
https://github.com/apple/swift/pull/5903 <https://github.com/apple/swift/pull/5903> - Allow SourceKit to be built by default on Linux (contains 5862)

Because SourceKit isn't currently built on Linux as part of the build process, it was missing dependencies on lto and coverage, both of which are needed to build successfully.

SourceKit depends on the native libdispatch implementation, which on Darwin is satisfied by the current platform. On Linux, the approach has been to build a two-pass of swift; first without the SourceKit support, and then with the SourceKit support. The second time around, the SourceKit build can pick up the libdispatch library from the previous build.

The fix I've implemented in pull 5903 is to add a dummy dependency when building SourceKit and on Linux that requires the libdispatch library exists, and if it doesn't, to shell out to make it. It's ugly, but it works, and SourceKit can be built in a single pass (though it still compiles libdispatch twice). This would allow SourceKit to be used on Linux for other tools to take advantage of.

More strategic solutions might look like:

* Refactoring the libdispatch build to use CMake - possibly unlikely, since the libdispatch project has dependencies on libkqueue and libpwq, both of which are external projects that use autoconf.
* Splitting out SourceKit to its own repository/project, and then interleaving the dependencies such that SourceKit could depend on the libdispatch project on Linux and not on Darwin.
* Changing the build script such that the libdispatch native library is built first, prior to the main Swift project, but build the libdispatch Swift code subsequently (potentially in a single repository, but may need two steps)

Since these alternatives require more work, and may not be applicable at the current time, I've taken the approach of creating the simplest thing that works (albeit unashamedly ugly) for pull 5903.

Comments welcome.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161122/18894ccf/attachment.html>

More information about the swift-dev mailing list