Skip to content

Add (partial) support for building on Windows using SwiftPM #7866

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

Merged
merged 1 commit into from
Aug 9, 2024

Conversation

jakepetroules
Copy link
Contributor

This adds a dependency on the new swift-toolchain-sqlite package, which allows swift-package-manager to build using swift build on Windows (including tests) without any additional flags or preinstalled dependencies.

It's "partial" because there is still one final blocker, which is that linking fails because we exceed the 65k exported symbol limit due to limitations in the build system, which can be addressed separately.

@MaxDesiatov
Copy link
Contributor

@swift-ci test

@jakepetroules jakepetroules enabled auto-merge (rebase) August 8, 2024 19:45
@jakepetroules
Copy link
Contributor Author

error: Dependencies could not be resolved because 'swift-llbuild' depends on 'swift-toolchain-sqlite' 0.1.0..<1.0.0.
'swift-toolchain-sqlite' >= 0.1.0 cannot be used because 'swift-toolchain-sqlite' 0.1.0 contains incompatible tools version (5.10.0) and no versions of 'swift-toolchain-sqlite' match the requirement 0.1.1..<1.0.0.

The macOS CI is still using Swift 5.9. Is this expected or should I bump down the tools version in swift-toolchain-sqlite from 5.10 to 5.9?

@jakepetroules
Copy link
Contributor Author

@swift-ci please test Windows

@jakepetroules
Copy link
Contributor Author

@swift-ci please test macOS

@bnbarham
Copy link
Contributor

bnbarham commented Aug 9, 2024

The macOS CI is still using Swift 5.9. Is this expected or should I bump down the tools version in swift-toolchain-sqlite from 5.10 to 5.9?

I'd prefer just bumping down for now. We should separately test bumping Utilities/Docker/Dockerfile up to 5.10

@@ -854,7 +856,8 @@ if ProcessInfo.processInfo.environment["SWIFTCI_USE_LOCAL_DEPS"] == nil {
.package(url: "https://github.com/swiftlang/swift-syntax.git", branch: relatedDependenciesBranch),
.package(url: "https://github.com/apple/swift-system.git", "1.1.1" ..< "1.4.0"),
.package(url: "https://github.com/apple/swift-collections.git", "1.0.1" ..< "1.2.0"),
.package(url: "https://github.com/apple/swift-certificates.git", "1.0.1" ..< "1.4.0"),
.package(url: "https://github.com/apple/swift-certificates.git", "1.0.1" ..< "1.6.0"),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needed to pull in apple/swift-certificates#180 which fixes a Windows build break

This adds a dependency on the new swift-toolchain-sqlite package, which allows swift-package-manager to build using swift build on Windows (including tests) without any additional flags or preinstalled dependencies.

It's "partial" because there is still one final blocker, which is that linking fails because we exceed the 65k exported symbol limit due to limitations in the build system, which can be addressed separately.
@jakepetroules
Copy link
Contributor Author

@swift-ci please test

@jakepetroules
Copy link
Contributor Author

@swift-ci please test windows

@jakepetroules jakepetroules merged commit b0b6e76 into main Aug 9, 2024
5 checks passed
@jakepetroules jakepetroules deleted the windows-sqlite3 branch August 9, 2024 09:32
jakepetroules added a commit that referenced this pull request Aug 12, 2024
This continues from the support added in #7866.

While we can't build on Windows as-is due to exceeding the 65k exported symbol limit, in turn due to limitations in the build system, we can apply -static to all of the library targets which are known to be linked statically, in order to get that symbol count down.

Note that this uses unsafeFlags, which is normally not recommended, however given that we are already using unsafeFlags elsewhere in the manifest, this seems reasonable enough for now until we can improve support for static linking on Windows.

Building the test targets still exceeds the symbol count though.
jakepetroules added a commit that referenced this pull request Aug 13, 2024
This continues from the support added in #7866.

While we can't build on Windows as-is due to exceeding the 65k exported symbol limit, in turn due to limitations in the build system, we can apply -static to all of the library targets which are known to be linked statically, in order to get that symbol count down.

Note that this uses unsafeFlags, which is normally not recommended, however given that we are already using unsafeFlags elsewhere in the manifest, this seems reasonable enough for now until we can improve support for static linking on Windows.

Building the test targets still exceeds the symbol count though.
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.

4 participants