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
rdar://109108066 (Derive '-external-plugin-path' compiler arguments in SwiftPM) #6560
Conversation
@swift-ci please smoke test |
Not really sure how to test this, but I manually checked that all Swift targets get the relevant arguments. |
Fun, looks like
I guess since this is supposed to be macOS only, we can conditionally compile. |
3e633ef
to
895d520
Compare
@swift-ci please smoke test |
@swift-ci please smoke test windows |
895d520
to
02f8393
Compare
@swift-ci please smoke test |
@swift-ci please smoke test windows |
1 similar comment
@swift-ci please smoke test windows |
@@ -392,6 +392,18 @@ public final class SwiftTargetBuildDescription { | |||
} | |||
#endif | |||
|
|||
// If we're using an OSS toolchain, add the required arguments bringing in the plugin server from the default toolchain if available. | |||
if self.buildParameters.toolchain.isSwiftDevelopmentToolchain, driverSupport.checkSupportedFrontendFlags(flags: ["-external-plugin-path"], toolchain: self.buildParameters.toolchain, fileSystem: self.fileSystem), let pluginServer = self.buildParameters.toolchain.swiftPluginServerPath { |
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.
not for this PR but we should change checkSupportedFrontendFlag
to take an enum instead of a string so we can centralize the usage of the string expression
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.
You mean for the flags we're checking? Seems a bit odd to do that specifically for checkSupportedFrontendFlag
when we're using literal strings all over the Build
module. I could see a broader change that uses a typed way for this everywhere, but IMO should be coming from the swift-driver library.
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.
yea, the problem is that all these strings everywhere can get out of sync and are focused on actual CLI invocation instead of on the capabilities. I think the call sites would be better if they look more like the following:
if driverSupport.supports(.externalPlugin) {
...
args += driverSupport.flag(for: .externalPlugin, with: value)
}
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.
Yep, I agree with that.
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.
some non-blocking suggestions
…n SwiftPM) This derives the required `-external-plugin-path` arguments when using an OSS toolchain with SwiftPM.
02f8393
to
5f786fe
Compare
@swift-ci please smoke test |
@swift-ci please smoke test windows |
No Windows, I guess ¯\_(ツ)_/¯ |
@swift-ci please smoke test windows |
This derives the required
-external-plugin-path
arguments when using an OSS toolchain with SwiftPM.