Rename `Install-Platform` to `Install-SDK` as it adjusts the SDK layout.
This is something that we should work towards minimising and ensuring
that the install rules in CMake properly stage the files. In the mean
time, this allows us to properly structure the SDK.
Alter the parameters to avoid the explicit OS, extracting it from the
platform set provided. Additionally provide an SDK identifier to allow
us to handle the experimental SDKs as well.
Add support to emit the SDKSettings.json for the experimental SDK. This
ensures that the we have the settings available for the tools when using
this SDK.
Alter the PList and JSON to match contents. While the primary consumer
for the PList is SPM, this synchronises the two just in case. This is in
response to feedback from @jakepetroules.
This adjusts the experimental runtime build to include the overlay,
StringProcessing, Synchronization. This is a first step towards getting
a sufficient amount of the SDK overlay built so that we can start
statically linking a real world program (swift-driver).
We currently cannot boostrap the toolchain with an early swift-driver.
Mark that we are using the old driver. Once the new experimental SDK is
packaged, we should be able to start building the early swift-driver
with static linking to use the bootstrapped driver.
Super surprised to see the build for swift test hardcoded in
the build.ps1 script instead of in the sourcekit-lsp repo.
At any rate, looks like I need to add the dependency on ASN1
here too.
This is to support changes in SwiftPM that add the dependency
which translates through to sourcekit-lsp.
https://github.com/swiftlang/swift-package-manager/pull/8610
Updates the build.ps1 script to add the SwiftASN1 package support
to it's CMake build. This was caused by this dependency being added
to a module in SwiftPM that sourcekit-lsp imports.
Further refine the build after the `LibraryRoot` removal. The
alterations here support the build to be generalised for
cross-compilation without worrying about a central installation for the
dependencies.
This is no longer used, preferring to stage the dependencies into the
toolchain image. The packaging step will simply ignore these files to
prevent shipping. This is important to support a multi-phase build as
well as a cross-compile for a host where the host binaries cannot run
on the build.
`-Clean` has generally been a psuedo-clean operation. It will clear out
the build trees excluding the costly compiler build. With the ability to
use caching now, make `-Clean` a fully clean build.
Teach build.ps1 to search for a pre-installed CMake and Ninja from the
PATH instead of only using one installed in Visual Studio. If one is not
installed or on the path, the script will attempt to use one installed
in Visual Studio. Preference is given to the executable found in the
path environment variable.
This feature never really was used in the CI systems as it was intended.
It was meant to allow doing partial builds for smoke testing. However,
we have a much better solution for that now: docker. Remove this feature
that is underutilized.
Ensure that we stage all the MSMs for the Windows Runtime distribution.
This enables us to consider online installers which would allow users to
select subsets of the installer to download when needed.
When the output is directly redirected, the output is re-encoded. This
is particularly important as `Write-PList` uses `Invoke-Program` to
invoke `python.exe` to write the plist. However, because it is writing
to a file, while the output from Python is in UTF-8, the redirection
re-encodes the output to UTF16LE (BOM). Adjust the invocation to use
PS7+ `2|` and pipe both stdout and stderr as appropriate into files with
UTF-8 encoding restoring the encoding for the file.
utils: adjust the emission of `SDKSettings.json`. Use lowercase spellings for the platform names to match SwiftBuild's expectations as pointed out by @jakepetroules.
