-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Pass through the toolchain to use for manifest loading #7639
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
@@ -128,6 +129,7 @@ public struct BuildDescription { | |||
return PluginTargetBuildDescription( | |||
target: target, | |||
toolsVersion: package.manifest.toolsVersion, | |||
toolchain: buildPlan.toolsBuildParameters.toolchain as? UserToolchain, |
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 very much dislike this, but ManifestLoader
has a bunch of uses of members in UserToolchain
that are not in Toolchain
. Should we add requirements for them all?
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.
If they make sense for Toolchain protocol, why not?
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.
Do we have any other implementations of Toolchain
other than UserToolchain
and MockToolchain
? If not, maybe we should reconsider our approach to mocking that doesn't require maintaining a separate protocol?
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.
There is a FIXME right on top of UserToolchain, might be the time to make it right...
let isPartOfRootPackage: Bool | ||
|
||
init(target: ResolvedModule, toolsVersion: ToolsVersion, isPartOfRootPackage: Bool) { | ||
init(target: ResolvedModule, toolsVersion: ToolsVersion, toolchain: UserToolchain?, isPartOfRootPackage: Bool) { |
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.
How about we pass BuildParameters
here which should allow us make toolchain
field non-Optional, we can assign it this way in the initializer:
self.toolchain = if let toolchain = buildParameters.toolchain as? UserToolchain {
toolchain
} else {
UserToolchain(swiftSDK: .hostSwiftSDK()))
}
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.
Ended up adding a static method to get the arguments and then adding swiftPMLibrariesLocation
to Toolchain
, which then gets rid of this optional problem entirely.
Prefer the toolchain provided in the build plan rather than the default host toolchain so that the returned arguments align with the toolchain used to construct the build plan.
2c0ef73
to
495894a
Compare
@swift-ci please test |
Prefer the toolchain provided in the build plan rather than the default host toolchain so that the returned arguments align with the toolchain used to construct the build plan.