-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Swift SDKs: implement swiftResourcesPath
#6717
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
Swift SDKs: implement swiftResourcesPath
#6717
Conversation
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.
SGTM overall modulo missing doc comments.
@swift-ci smoke test |
swiftResourcesPath
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.
Thanks!
BuildDescription: propagate resources to clang too Doc comments feedback
af85360
to
1561e81
Compare
@MaxDesiatov mind kicking off CI again? Had to rebase on top of 0e50b63. |
@@ -218,6 +219,7 @@ public final class ProductBuildDescription: SPMBuildCore.ProductBuildDescription | |||
self.observabilityScope.emit(.swiftBackDeployError) | |||
} else if self.buildParameters.targetTriple.isSupportingStaticStdlib { | |||
args += ["-static-stdlib"] | |||
hasStaticStdlib = true |
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.
Shouldn't shouldLinkStaticSwiftStdlib when !isSupportingStaticStdlib be an error?
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.
Perhaps refactor this to match the style of https://github.com/apple/swift-package-manager/pull/6717/files#diff-31b280ef997c175a0c39198547ce45d473e9fb89ac71aaa5ed2ad7e4a92473c8R934
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.
It seems a bit harder to adopt that approach here because the inclusion of -static-stdlib
in the linker invocation also depends on the product type. If I understand your point correctly, I agree that there should be better validation around shouldLinkStaticSwiftStdlib
(e.g. emitting an error if the product is a dynamic library) but imo that would be better suited to a follow-up PR since it's orthogonal to this change — what do you think?
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.
A follow-up PR is fine by me, but in that case would you mind adding a TODO or FIXME note in code comments? I hope this would be addressed sooner rather than later.
We usually squash and merge here, so there's no need to rebase unless you really prefer that workflow. A lot of times a merge commit is easier to resolve conflicts with, and it won't show up after squash and merge in the target branch anyway. |
Gotcha, will keep that in mind — wasn't sure about the convention since it seems they do merge commits over on apple/swift. |
@@ -243,6 +246,16 @@ public final class ProductBuildDescription: SPMBuildCore.ProductBuildDescription | |||
throw InternalError("unexpectedly asked to generate linker arguments for a plugin product") | |||
} | |||
|
|||
if let resourcesPath = self.buildParameters.toolchain.swiftResourcesPath(isStatic: isLinkingStaticStdlib) { | |||
args += ["-resource-dir", "\(resourcesPath)"] |
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.
@MaxDesiatov is it correct to rely on interpolation here instead of pathString
?
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.
should this just move into the hmm read this wrongif self.buildParameters.shouldLinkStaticSwiftStdlib
branch? its used only there it seems
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.
Interpolation will render it properly on Windows: https://github.com/apple/swift-package-manager/blob/14ff299060cfd7f1bab3a4fc9065f77d427f8093/Sources/Basics/FileSystem/NativePathExtensions.swift#L16
@swift-ci smoke test |
@swift-ci test windows |
@swift-ci test |
This seems to have broken SPM on Windows, I'm going to revert this for now, please make sure to run the tests on Windows locally in the future. |
isn't this what CI is for? can we get the tests running on CI? |
@compnerd Would you be able to provide the exact error message? This would help us fix the issue with no readily available local access to Windows and no testing set up on CI either. +1 to Tom's question why wasn't this caught on CI in the first place? |
@MaxDesiatov I think that it was actually the change after this (XCTest integration), at least after a bit more digging. This wasn't caught on CI due to the test suite not running in CI, only building SPM. |
This PR implements
swiftResourcesPath
andswiftStaticResourcesPath
from theswift-sdk.json
spec.Motivation:
SwiftPM previously knew how to parse these fields from the SDK manifest, but didn't actually do anything with them.
Modifications:
-resource-dir
to swiftc for compile jobs-resource-dir
to both swiftc and clang for link jobsResult:
Toolchains that override
swiftResourcesPath
and/orswiftStaticResourcesPath
should now behave as expected.