Improve handling of non-macOS Darwin triples (reprise) #6732
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kabiroberai
requested review from
abertelrud,
neonichu,
tomerd and
MaxDesiatov
as code owners
It doesn't make sense to do this on other OSes since it's likely a cross-compiled build, so adding the host swift-5.5 to the rpath is meaningless. Instead, clients must package the back-deployment libs in their app bundle.
Co-Authored-By: Aleksei Sapitskii <45671572+aleksproger@users.noreply.github.com>
kabiroberai
changed the title
neonichu
approved these changes
Aug 16, 2023
|
@swift-ci please smoke test |
MaxDesiatov
approved these changes
Aug 17, 2023
MaxDesiatov
added a commit
that referenced
this pull request
Jan 2, 2024
…#6963) Product dependencies are now verified using the `buildEnvironment`'s platform, instead of the hardcoded `macOS` platform. This builds on the work of #6732, now allowing cross-compilation of product dependencies 🎉 ### Motivation: Let's say we're cross-compiling macOS -> iOS simulator, with a host system of `macOS v13`. ```swift let package = Package( name: "SwiftFlashlight", products: [.library(...)], platforms: [.iOS(.v16)], dependencies: [ // internally, for iOS(.v16), macOS(.v14) .package(url: "probably/alamofire", exact: "1.2.3") ], // ... ) ``` As long as we set our triple & SDK, we _should_ be good... (and, with #6828, only the triple needed) ```fish > swift build --triple arm64-apple-ios-simulator \ --sdk "$(xcrun --sdk iphonesimulator --show-sdk-path)" ... error: the library 'SwiftFlashlight' requires macos 10.13, but depends on the product 'probably/alamofire' which requires macos 10.14; [...] ``` Even though `SwiftFlashlight` only supports `iOS(.v16)`, [SupportedPlatform](https://github.com/apple/swift-package-manager/blob/main/Documentation/PackageDescription.md#supportedplatform) "[by] default, [...] assigns a predefined minimum deployment version for each supported platforms unless you configure supported platforms [...]". As a side-effect, `macOS` is inferred as a valid platform. (This is why no "target/platform mismatch" error was thrown.) Previously, product dependencies were verified against `macOS`, rather than the target platform. Since `macOS` is always inferred, this surfaced as a "woah! your dependencies are out of sync". ```swift let swiftFlashlight = Package( platforms: [ .iOS(.v16), .macOS(.v13) // <-- inferred-| ], | ) |-- // since --triple is .iOS, | // shouldn't be comparing let probably/alamofire = Package ( | // macOS. platforms: [ | iOS(.v16), | macOS(.v14)] // <-- inferred-| ] ) ``` Now, the intention of `--triple` is respected 🐱 ### Modifications: - `validateDeploymentVersionOfProductDependency` accepts a `buildEnvironment` containing the target platform ### Result: Product dependencies can now be compiled for `darwin` other than macOS -- i.e, iOS :) ### Future work - Target-level or product-level platform support is still up in the air - This only applies to `triple.isDarwin()` -- perhaps a next step of verifying dependencies against non-darwin? --------- Co-authored-by: Max Desiatov <m_desiatov@apple.com>
dschaefer2
pushed a commit
that referenced
this pull request
Oct 28, 2024
This change makes it possible to run e.g. `swift build --triple arm64-apple-ios` on macOS to build for iOS. ### Motivation: With #6732 in place, it's possible to use `swift-build` for most Darwin targets on macOS with `swift build --triple arm64-apple-ios --sdk $(xcrun --sdk iphoneos --show-sdk-path)` etc. The `SwiftSDK` type already has support for computing a "default" SDK given a triple, so we can elide the `--sdk` argument by automatically inferring it on macOS. ### Modifications: - Generalize `hostSwiftSDK` as a `systemSwiftSDK` function that additionally accepts a Darwin platform as an argument. On macOS, this allows us to compute a `SwiftSDK` that works for arbitrary Darwin targets, instead of just macosx. - Modify `defaultSwiftSDK(for:)` to return a non-macOS Darwin `systemSwiftSDK` if requested. - Modify the `SwiftTool._targetToolchain` computation to handle default SDKs passed via `--swift-sdk`, not just `--triple`. (Open to discussing whether this change is a good idea.) ### Result: Darwin targets get free Swift SDK support on macOS 🎉 ### Open questions: Should default Swift SDKs be usable via `--swift-sdk`, and should they show up in `swift sdk list`? These two changes would ensure homogeneity; for example, if/when SourceKit-LSP supports SDK selection this would enable Darwin targets on macOS there too.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR improves the way that iOS and other non-macOS Darwin triples are handled. Somewhat based on #6572, accounting for the changes since then.
Motivation:
We can't assume that darwin == macOS anymore, necessitating a few changes to handle the other OSes.
Modifications:
.iOS(.v16)now impliesarm64-apple-ios16)Result:
iOS/tvOS/watchOS libraries and (xc)frameworks are now better supported.