-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Runtime: extract a Runtime subdirectory for SPM #9063
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
f3a5555
to
5cb3585
Compare
Can you elaborate on some of the higher level goals behind this change? |
@jakepetroules sure - the higher level goal here is to get to the point where we can build the Swift toolchain on Windows with the bootstrap compiler. With the new experimental SDK, we have Win32 SxS runtimes available and I would like to embed the runtime into the compiler itself. allowing the toolchain to run against the runtime that it was built against while uniformly building all the tools against the same runtime and the same compiler. Currently, the SPM Manifest runtime is built with the just built compiler and runtime as we build the vast majority of the toolchain with the just built compiler and runtime and rely on luck to build the swift frontend with the bootstrap compiler and runtime and then run against the new runtime (without ABI stability). This restructuring (it is mostly a move of 3 of the modules) allows us to create a separate subproject that will build only |
@swift-ci please smoke test |
@swift-ci please test |
@swift-ci please smoke test Linux platform |
Please test with following PRs: @swift-ci please smoke test |
714a90e
to
b757253
Compare
Please test with following PRs: @swift-ci please smoke test |
Can this be done without the large number of moves? |
Please test with following PRs: @swift-ci please smoke test |
No, that cannot be done. The large number of moves is due to the DocC bundles being checked in. We could remove the DocC bundles potentially. But we do need to have a new directory in between to allow building as a separate project, so the remaining moves (which are pretty small) need to be done. |
Please test with following PRs: @swift-ci please test macOS platform |
Please test with following PRs: @swift-ci please test macOS platform |
Please test with following PRs: @swift-ci please test |
Please test with following PRs: @swift-ci please test Windows |
1 similar comment
Please test with following PRs: @swift-ci please test Windows |
Please test with following PRs: @swift-ci please test |
Please test with following PRs: @swift-ci please test Windows |
Please test with following PRs: @swift-ci please smoke test Windows platform |
Took a look at the macOS failure. The bootstrap script has this existing code:
which looks like an attempt to set the deployment target without configuring the target triple on the compile. Based on the logs, when we build SystemPackage in the bootstrap script, it only runs the link step. So we may be building a copy of SystemPackage earlier in the build without an explicit deployment target (defaulting to 15.0 since that's the builder version), then trying to rebuild later with this |
Thanks @owenv! I think that it might've been that we weren't passing |
Re-organise the "runtime" components (i.e. the Package Manifest runtime) into a separate directory. Introduce a separate CMake project for the build of this runtime to allow building the SPM tool with one version of the Swift runtime and the SPM Manifest Runtime witih a separate Swift runtime.
Please test with following PRs: @swift-ci please test |
Please test with following PRs: @swift-ci please test Windows platform |
Please test with following PRs: @swift-ci please test Windows platform |
Please test with following PRs: @swift-ci please smoke test Windows platform |
Please test with following PRs: @swift-ci please test Windows platform |
level=logging.INFO, | ||
) | ||
g_macos_deployment_target = '12.0' | ||
g_macos_deployment_target = '14.0' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any chance we could tie this to DARWIN_DEPLOYMENT_VERSION_OSX in swiftlang/swift?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how to do that tbh; I think that the best way to do that would be to get rid of this script and drive this process through the tooling in swiftlang/swift.
Please test with following PRs: @swift-ci please test macOS platform |
Re-organise the "runtime" components (i.e. the Package Manifest runtime) into a separate directory. Introduce a separate CMake project for the build of this runtime to allow building the SPM tool with one version of the Swift runtime and the SPM Manifest Runtime witih a separate Swift runtime.