Skip to content

Conversation

compnerd
Copy link
Member

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.

@compnerd compnerd force-pushed the runtime branch 2 times, most recently from f3a5555 to 5cb3585 Compare August 26, 2025 17:24
@jakepetroules
Copy link
Contributor

Can you elaborate on some of the higher level goals behind this change?

@compnerd
Copy link
Member Author

@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 PackageDescription, CompilerPluginSupport, and PackagePlugin modules separately. In doing so, we can now build the package manager with the old runtime and compiler, the SPM manifest runtime with the new runtime and compiler so that we can consume this in a safe way.

@compnerd
Copy link
Member Author

@swift-ci please smoke test

@compnerd
Copy link
Member Author

@swift-ci please test

@compnerd
Copy link
Member Author

@swift-ci please smoke test Linux platform

@compnerd
Copy link
Member Author

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please smoke test

@compnerd compnerd force-pushed the runtime branch 3 times, most recently from 714a90e to b757253 Compare September 24, 2025 18:55
@compnerd
Copy link
Member Author

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please smoke test

@rconnell9
Copy link
Contributor

Can this be done without the large number of moves?

@compnerd
Copy link
Member Author

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please smoke test

@compnerd
Copy link
Member Author

compnerd commented Sep 25, 2025

Can this be done without the large number of moves?

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.

@compnerd
Copy link
Member Author

compnerd commented Oct 6, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test macOS platform

@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test macOS platform

@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test

@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test Windows

1 similar comment
@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test Windows

@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test

@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test Windows

@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please smoke test Windows platform

@owenv
Copy link
Contributor

owenv commented Oct 7, 2025

Took a look at the macOS failure. The bootstrap script has this existing code:

if platform.system() == 'Darwin':
        call(["sed", "-i", "", "s/macosx10.10/macosx%s/" % (g_macos_deployment_target), "build.ninja"], cwd=build_dir)

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 sed hack and not actually rebuilding. The only problem with that guess is that I can't find any other builds of SystemPackage elsewhere in the log.

@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Thanks @owenv! I think that it might've been that we weren't passing -D CMAKE_Swift_COMPILER_TARGET to the swift-system build, resulting in the default value from the compiler being used for the deployment target for the Swift code. 🤞 that this version passes the macOS smoke test (seems to be getting further!)

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.
@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test

@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test Windows platform

@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test Windows platform

@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please smoke test Windows platform

@compnerd
Copy link
Member Author

compnerd commented Oct 7, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test Windows platform

level=logging.INFO,
)
g_macos_deployment_target = '12.0'
g_macos_deployment_target = '14.0'
Copy link
Contributor

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?

Copy link
Member Author

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.

@compnerd
Copy link
Member Author

compnerd commented Oct 8, 2025

Please test with following PRs:
swiftlang/swift#84473

@swift-ci please test macOS platform

@compnerd compnerd merged commit 3aff8af into swiftlang:main Oct 8, 2025
6 checks passed
@compnerd compnerd deleted the runtime branch October 8, 2025 14:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants