Skip to content

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

Merged
merged 6 commits into from
Sep 7, 2023

Conversation

kabiroberai
Copy link
Contributor

This PR implements swiftResourcesPath and swiftStaticResourcesPath from the swift-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:

  • Pass -resource-dir to swiftc for compile jobs
  • Pass -resource-dir to both swiftc and clang for link jobs

Result:

Toolchains that override swiftResourcesPath and/or swiftStaticResourcesPath should now behave as expected.

Copy link
Contributor

@MaxDesiatov MaxDesiatov left a 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.

@MaxDesiatov
Copy link
Contributor

@swift-ci smoke test

@MaxDesiatov MaxDesiatov changed the title Swift SDKs: implement swiftResourcesPath Swift SDKs: implement swiftResourcesPath Jul 18, 2023
@MaxDesiatov MaxDesiatov self-assigned this Jul 18, 2023
Copy link
Contributor

@MaxDesiatov MaxDesiatov left a 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
@kabiroberai kabiroberai force-pushed the resource-dir-overrides branch from af85360 to 1561e81 Compare July 18, 2023 16:00
@kabiroberai
Copy link
Contributor Author

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

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?

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

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?

Copy link
Contributor

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.

@MaxDesiatov
Copy link
Contributor

@MaxDesiatov mind kicking off CI again? Had to rebase on top of 0e50b63.

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.

@kabiroberai
Copy link
Contributor Author

Gotcha, will keep that in mind — wasn't sure about the convention since it seems they do merge commits over on apple/swift.

@MaxDesiatov MaxDesiatov requested a review from rauhul July 18, 2023 18:29
@@ -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)"]
Copy link
Contributor Author

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?

Copy link
Contributor

@tomerd tomerd Jul 20, 2023

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 if self.buildParameters.shouldLinkStaticSwiftStdlib branch? its used only there it seems hmm read this wrong

Copy link
Contributor

Choose a reason for hiding this comment

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

@MaxDesiatov
Copy link
Contributor

@swift-ci smoke test

@MaxDesiatov
Copy link
Contributor

@swift-ci test windows

@MaxDesiatov
Copy link
Contributor

@swift-ci test

@MaxDesiatov MaxDesiatov merged commit 76e3594 into swiftlang:main Sep 7, 2023
@compnerd
Copy link
Member

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.

compnerd added a commit that referenced this pull request Sep 12, 2023
@tomerd
Copy link
Contributor

tomerd commented Sep 12, 2023

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?

@MaxDesiatov
Copy link
Contributor

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.

@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?

@compnerd
Copy link
Member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants