[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](f7cf1e3b63/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`.
* 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
* Switch android tools installation to cmdline-tools
* Replace deprecated sdkmanger from sdk-tools to the one from cmdline tools
* Remove patcherv4 from toolsets as it's included in m2repository extras
* Add tests to make sure both sdkmanagers exist
* Return cmdline-tools to software readme
* Get-AndroidInstalledPackages function now use list_installed param
* Create a function to get sdkmanager version = cmdline tools version
* Get rid of hardcoded path to ANDROID_HOME
* Add reloadEtcEnvironment call to installation script
* Use env variable ANDROID_HOME in tests
* Modify software report to output any version
* Change regex pattern to output the group
* Currently the function returns 4. instead of 4.0, this change fixes it
* Remove php installation, tests and software docs for Ubuntu 16
* Add openssl 1.1.1k installation as python toolcache depends on it
* Add a comment about openssl installation on Ubuntu 16
