[SourceKitten](https://github.com/jpsim/SourceKitten), a popular Swift
library for interacting with SourceKit, needs to know (or be told) the
location of the sourcekitd framework. SourceKitten is somewhat
[ubiquitous](https://github.com/jpsim/SourceKitten#projects-built-with-sourcekitten);
most Swift projects I've seen or worked on used SourceKitten in some
way.
On macOS, the sourcekit framework is baked-in to the Xcode toolchain(s) and
therefore its location is generally known. On Linux, the location of the
sourcekit framework is wherever swift is installed, which is unknown to
libraries like SourceKitten.
SourceKitten searches for the sourcekit framework in [a few
locations](https://github.com/jpsim/SourceKitten/blob/f7cf1e3b6328f21e344e83450ae1298af69de281/Source/SourceKittenFramework/library_wrapper.swift#L51-L104),
but it's unable to infer the location of the framework on these ubuntu
images. The result when attempting to run any SourceKitten-based tool in
Github Actions on an ubuntu VM is the following error:
```
SourceKittenFramework/library_wrapper.swift:31: Fatal error: Loading libsourcekitdInProc.so failed
/home/runner/work/_temp/cb002a5e-1916-4e05-ba4d-f70ad3bb2266.sh: line 1: 3944 Illegal instruction (core dumped) mint run swiftlint .
```
(to be clear, this error is not specific to the Github Actions ubuntu
VMs. The same error occurs on any Ubuntu system).
Individual users can work around this by setting the following
environment variable:
```
LINUX_SOURCEKIT_LIB_PATH="/usr/share/swift/usr/lib"
```
This is not a good workaround for the following reasons:
1. The end user doesn't necessarily know where swift is installed.
2. A change to the location of the swift installation would break this
workaround.
3. The error will occur virtually 100% of the time on a user's first
attempt to run SourceKitten on ubuntu, and takes at least a
few minutes to troubleshoot. This will quickly add up to a
non-trivial amount of lost productivity.
So, anyways, my proposal is to just link sourcekitd to a location where
SourceKitten will find it, so most developers don't have to think about it.
`LINUX_SOURCEKIT_LIB_PATH` can be defined by the user if they have an
unusual setup.
Alternative:
- Don't symlink, add `LINUX_SOURCEKIT_LIB_PATH` to `/etc/environment`.
* pull previous version of chromium if revision is 4 digits long
* add example revisions that break build
* use json instead of csv when retrieving previous versions
* grab revision, not version
