build.ps1: use pinned toolchain rather than built toolchain #84361
Conversation
|
@swift-ci please build toolchain Windows platform |
|
@swift-ci please build toolchain Windows platform |
Use the experimental SDK to build the toolchain and consume the redistributable. This is going to ensure that we build the entire toolchain against a stable point and run against the runtime that we build against.
Adjust the toolchain build to use the pinned toolchain rather than the built toolchain. This is particularly important with the lack of ABI stability on Windows. We now uniformly build the toolchain with the same runtime. This extricates the SDK from the toolchain build. Now that we build the toolchain properly against a SxS installable version of the runtime, we can consume the runtime that we built against and inject that into the toolchain image. This avoids the need to rely on trying to maintain ABI compatibility in an ABI unstable environment.
|
@swift-ci please build toolchain Windows platform |
|
This is gonna require matching changes on github actions. |
|
@mhegazy yeah; but turns out that this unfortunately might be required to really extricate XCTest and Testing from the SDK build. I've been trying to do that in the reverse form and have not been successful. Locally, I've been building against the pinned toolchain and it simplifies the SDK build quite a bit. Unfortunately, this is going to break SPM in the process and requires a coordinated change for that. There are a number of intertwined pieces :( |
|
understood. need to keep track of changes to apply |
|
Please test with following PRs: @swift-ci please build toolchain windows platform |
Now that we build against the pinned toolchain and runtime rather than the just built runtime, we re-order the build to build the SDK _after_ the runtime is completed. This simplifies the rules and ensures that we do not mix the runtime and the toolchain.
With the toolchain being completely built, we can run the toolchain out of the staged environment rather than the build tree. This is important as a preparatory step - we now can extract the SxS runtime into the new staged location.
For some reason SourceKit-LSP tests fail to build with undefined references to collection modules. Add the additional library search paths to resolve the modules.
|
@swift-ci please build toolchain windows platform |
Adjust the toolchain build to use the pinned toolchain rather than the built toolchain. This is particularly important with the lack of ABI stability on Windows. We now uniformly build the toolchain with the same runtime. This extricates the SDK from the toolchain build.
Now that we build the toolchain properly against a SxS installable version of the runtime, we can consume the runtime that we built against and inject that into the toolchain image. This avoids the need to rely on trying to maintain ABI compatibility in an ABI unstable environment.