-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Cross compilation improvements #7593
Conversation
@@ -26,6 +26,18 @@ public struct BuildParameters: Encodable { | |||
case auto | |||
} | |||
|
|||
/// The destination for which code should be compiled for. | |||
public enum Destination: Encodable { |
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 think this is an intermediate type that currently connects to buildTriple
for each resolved product/module. As a follow up to these changes I'm planning to remove buildTriple
, this could only be accomplished if a build plan could be formed earlier than today and all of the "destination" handling would be moved there. Modules graph would have destination-less products/modules and build plan would be responsible for determining destinations and building complete set of host/target build descriptions that other types can query if they need a product/module for a particular destination. I major obstacle to this "plan" is how plugins are built/invoked - they create a separate build command and subsequently a new build plan etc. I'm hoping to change that and make plugins/
directory obsolete.
@swift-ci please build toolchain macOS platform |
…nation The change is introduced by swiftlang/swift-package-manager#7593
Sources/Build/BuildManifest/LLBuildManifestBuilder+Product.swift
Outdated
Show resolved
Hide resolved
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.
This makes sense, but needs conflicts resolved for CI to run. Also unsure if newly declared symbols need to be public
instead of package
, otherwise why not hide them with @_spi
.
…hrough the graph First step on the way to hide and remove `all{Products, Targets}` from modules graph because with cross-compilation attempting to fetch data from them directly could produce surprising results since they don't always account for build triples.
… modules graph Build plan data structures refer to the underling module/product in their descriptions so some of the uses of module graph's `allTargets` and `allProducts` could be removed in favor of getting the same information directly from descriptions in the build plan.
… through product/target descriptions Instead of looking through the build description and passing data from it down to underlying module/product, let's provided convenient APIs directly on build descriptions.
`BuildParameters` could either be used for `host` to `target` builds, add an ability to indicate that and switch `suffix` to use that information instead of requiring triple to be passed in. This helps avoid mismatches and makes it harder to mix us parameter's intended use.
91155bc
to
aad559f
Compare
swiftlang/sourcekit-lsp#1361 |
swiftlang/sourcekit-lsp#1361 |
Instead of using unified `buildParameters:` let's switch over to a more fine-grained control over build plan construction and allow setting common driver, linker and other flags but handle destinations internally.
…t targets Pass macros associated with a particular swift target as a list of build descriptions. That was the only users of `tools` build parameters that are now obsolete.
…rs` to `buildParameters`
… that plugin depends on Create a new executable product if plugin depends on an executable target. This is necessary, even though PackageBuilder creates one already, because that product is going to be built for `destination`, and this one has to be built for `tools`.
…ecursively` Plugins don't actually need whole graph to be switched to use `.tools` triple because `PluginTarget.processAccessibleTools` is able to find targets/products that have to be built for the host, it just needs a way to signal that to the build system. `Buildset` has been extended to support a destination which is defaulted to `.target` because really only plugin (command) tools have to set it to `.host`, this helps to propagate the information about expected destination down through `BuildOperation.build(subset:)` and find correct llbuild names and build products.
aad559f
to
6aaf53d
Compare
swiftlang/sourcekit-lsp#1361 |
swiftlang/sourcekit-lsp#1361 |
I confirmed I am able to remove the following workarounds from swift-mmio with this change.
I used a toolchain built from this PR and running in |
…stination modules Remove incorrect assumption that the outputs of the plugin are always connected to a destination build of a particular module and add a build triple into the path to separate the outputs of a plugin. This comes into play when i.e. a test is built for both `tools` and `destination`, we need two plugin invocations to handle that.
… a destination The products and targets are currently indentified by their package + name + build triple and they should be looked up in the same fashion to avoid situations when results of `product(for:)` and `target(for:)` return target that has an unexpected destination.
…nd plugins `Buildset` provided by `SwiftBuildCommand` cannot have right destination because it doesn't know what kind of product/target it's attempting to build so we need to fix that up in `computeLLBuildTargetName` until there is a way to properly express that via command line options.
…ethods into computed properties
6aaf53d
to
799c0dd
Compare
swiftlang/sourcekit-lsp#1361 |
swiftlang/sourcekit-lsp#1361 |
swiftlang/sourcekit-lsp#1361 |
1 similar comment
swiftlang/sourcekit-lsp#1361 |
…nation The change is introduced by swiftlang/swift-package-manager#7593
swiftlang/sourcekit-lsp#1361 |
swiftlang/sourcekit-lsp#1361 |
swiftlang/sourcekit-lsp#1361 |
…nation The change is introduced by swiftlang/swift-package-manager#7593
…nation The change is introduced by swiftlang/swift-package-manager#7593 (cherry picked from commit 12b848e)
…nation The change is introduced by swiftlang/swift-package-manager#7593 (cherry picked from commit 12b848e)
…nation The change is introduced by swiftlang/swift-package-manager#7593 (cherry picked from commit 12b848e)
…nation The change is introduced by swiftlang/swift-package-manager#7593 (cherry picked from commit 12b848e)
Reenables SVD2SwiftTests and SVD2SwiftPluginTests when building with SwiftPM 6.0 or newer. The bug which required disabling these tests was resolved in swiftlang/swift-package-manager#7593.
Reenables SVD2SwiftTests and SVD2SwiftPluginTests when building with SwiftPM 6.0 or newer. The bug which required disabling these tests was resolved in swiftlang/swift-package-manager#7593.
A collection of fixes and improvements related to cross-compilation.
Motivation:
An attempt to make cross-compilation support more robust, consistent, error-prone and deal with performance regressions related to plugins.
Modifications:
BuildParameters
are now associated with a destination (host or target) to make sure that they are always used in accordance with their original purpose.Buildset
gains a defaultfor:
parameter to indicate the intended destination of a product/targetbuildTriple
of an product/targetallTargets
andallProducts
to use the graph and supply an intended destinationSwiftTargetBuildDescription
no longer needs to referencetoolsBuildParameters
by reworking the way requires macrosare referenced
ModulesGraph.updateBuildTripleRecursively
check{Target, Product}
default to.destination
Result:
swift build
with--target
and--product
now behave consistently