[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
* Add install of dotnet tools
- Add new section under dotnet.
- Add installer for dotnet tools.
- Add tests for dotnet tools.
- Add dotnet tools to software report.
* Fixes from code review
* Add test and version check to dotnet tool json
- Rework installer to use tool name.
- Rework test to call tool test.
- Rework software report to use tool specific command to get version.
* Fixes from code review
* Fix test for nbgv
* Fix linux installer
* Fix name for test context.
* Update images/linux/scripts/installers/dotnetcore-sdk.sh
Co-authored-by: PJ <me@panekj.dev>
* Update images/win/scripts/SoftwareReport/SoftwareReport.Common.psm1
Co-authored-by: PJ <me@panekj.dev>
* Update images/win/scripts/Tests/DotnetSDK.Tests.ps1
Co-authored-by: PJ <me@panekj.dev>
* Aligning PS1 between win and linux
* Remove out
* Add Nuget.org as feed source for installing tool
* Fix tests
* Fix getting tool version
* Change from code review
* Update images/win/toolsets/toolset-2022.json
Co-authored-by: Mikhail Timofeev <48208649+miketimofeev@users.noreply.github.com>
* Update images/win/toolsets/toolset-2019.json
Co-authored-by: Mikhail Timofeev <48208649+miketimofeev@users.noreply.github.com>
* Update images/win/toolsets/toolset-2016.json
Co-authored-by: Mikhail Timofeev <48208649+miketimofeev@users.noreply.github.com>
* Changes from code review
* Change from code revision
* Fix tests
* dotnet tool is now installed to a tool path
* Move dotnet tools install
- Need to install the dotnet tools AFTER post install steps otherwise dotnet is not in the path.
* Fxi typo in path
* Add path to software report for dotnet tools
* Remove new line (from code review)
* Add progress output message to dotnet tools install
* Change install path for tool
* New updating PATH with dotnet tools location
* Remove duplicated assigment
* Remove output message and add back Out-null
Co-authored-by: PJ <me@panekj.dev>
Co-authored-by: Mikhail Timofeev <48208649+miketimofeev@users.noreply.github.com>
* Add verbosity during software report generation
* Fix Get-CpanVersion
* set default ValidateExitCode value to $true
* update java test
* use lower-case for parameters
