Previously, the static Foundation build was linking against the dynamic
Dispatch build, resulting in a build failure when linking against the
static Foundation. This fixes the issue by linking the static Foundation
build against the static Dispatch build.
Rather than pass along build configuration context to the subsequent
builds, wire together the CMake configuration to the builds to allow
building the runtime properly.
The experimental stdlib runtime build has several sources files,
resulting in an absolutely massive commandline. This seems to be
approaching, or passing, the maximum command line length on Windows.
Switch the Windows build to use a response file generated by CMake to
pass the source files to the compiler.
Passes the value of the environment variable `TOOLCHAIN_VERSION` through
to Swift's `SWIFT_TOOLCHAIN_VERSION` for use in eg.
`-print-target-info` (and some day, `--version`).
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.
