-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
plugins: Global compiler flags should not be used for plugin dependencies #7549
base: main
Are you sure you want to change the base?
Conversation
@swift-ci test |
Test to follow. |
3294290
to
abaedbf
Compare
@swift-ci test |
@@ -741,7 +741,7 @@ package final class SwiftCommandState { | |||
configuration: options.build.configuration, | |||
toolchain: toolchain, | |||
triple: triple, | |||
flags: options.build.buildFlags, | |||
flags: toolsBuild ? .init() : options.build.buildFlags, |
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.
buildFlags
is a combination of C/C++/Swift/Linker/XCBuild which means that host compiler doesn't get any of them but are there situations when some of the flags intended for the host and/or tools?
At the very list I think descriptions of all flags and not just swiftCompilerFlags
have to be updated to indicate that they are no longer applied to the host.
@@ -796,7 +796,7 @@ package final class SwiftCommandState { | |||
|
|||
private lazy var _toolsBuildParameters: Result<BuildParameters, Swift.Error> = { | |||
Result(catching: { | |||
try _buildParams(toolchain: self.getHostToolchain()) | |||
try _buildParams(toolchain: self.getHostToolchain(), toolsBuild: 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.
Maybe instead of a boolean flag here we should just pass in the options.build.buildFlags
or []
?
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.
Yes, I think that's better and will help when we tidy up the tools/products build option split.
…n dependencies Build tools and end products are built with separate toolchains: * Plugins and any targets they depend on, such as helper tools, are built with the host toolchain. * End products are built with the target toolchain. Compiler flags set with -Xswiftc are intended to be applied only to end product builds, but they are incorrectly being applied to plugin tool builds as well. This can cause problems because target toolchain flags might not be suitable for a tools build. In the worst case, the build might fail completely if the host toolchain rejects the target toolchain flag. For example, Linux toochains accept the `-static-executable` flag, but macOS toolchains reject it. Fixes: rdar://127813618
abaedbf
to
8a8a86a
Compare
@swift-ci test |
@swift-ci test windows |
Motivation:
Build tools and end products are built with separate toolchains:
are built with the host toolchain.
Compiler flags set with
-Xswiftc
are intended to be applied only toend product builds, but they are incorrectly being applied to
plugin tool builds as well. This can cause problems because target
toolchain flags might not be suitable for a tools build. In the
worst case, the build might fail completely if the host toolchain
rejects the target toolchain flag. For example, Linux toochains
accept the
-static-executable
flag, but macOS toolchains rejectit.
Modifications:
Global compiler flags are no longer applied to
toolsBuildParameters
and so are no longer used when building plugin dependencies.
Result:
Plugin dependency builds will no longer fail because of incompatible
flags.
In future, the hidden
-Xbuild-tools-swift
flags should be passed tocommand plugin tools builds. These are currently only passed to the
plugin script runner.
Fixes: rdar://127813618