[Accepted in principle] SE-0387: Cross-Compilation Destination Bundles

Evolution Proposal Reviews
1

The review of SE-0387: Cross-Compilation Destination Bundles ended on February 14th, 2023, and the core team has decided to accept the proposal in principle the following modifications. Also, return it for re-review focused on naming convention. There is a new review thread for that discussion.

  • In toolset files the name of the extraFlags property that provides additional command-line options for each tool seemed misleading. Its value may contain not only flags, but any command-line options. extraCLIOptions is a self-descriptive name and could be used as a better alternative.
  • The proposed schema for destination.json metadata is not flexible enough to support bundles with multiple triples, it should be extended to support this type of bundles. As each triple uniquely identifies a set of properties, the updated schema should allow specifying a dictionary from a triple string used as a key to an inner dictionary with triple-specific properties and their values.
  • Since the existing swift package-collection command uses remove as a verb, swift destination delete should be renamed to swift destination remove for consistency.

Since "cross-compilation destination" is quite a mouthful, "Swift SDK" is proposed as an alternative name for the feature. With compilers for different languages "SDK" concept can mean a loosely defined collection of files used for multiple purposes. Proposed "Swift SDK" should be distinct from that, it denotes a bundle providing necessary infrastructure to compile a Swift package for a specific triple. CLI commands, options, and files within bundles should be renamed accordingly:

  • swift destination command renamed to swift sdk
  • proposed --destination option renamed to --swift-sdk
  • --destinations-path option renamed to --swift-sdks-path
  • ~/.swiftpm/destinations path renamed to ~/.swiftpm/swift-sdks
  • destination.json file renamed to swift-sdk.json
5 Likes
2

Great to see this moving forward, thanks to @Max_Desiatov for working on this. I know I had a lot of feedback on this proposal, but I hope to use these bundles for Android, so I'm obsessive about getting it right.

With Swift's extensive cross-compilation support, this feature could really showcase that and differentiate the language moving forward.

Presumably this refers to build-time triples, as this proposal has always supported multiple runtime triples.

This effort inspired me to work on getting runtime libraries for multiple CPU architectures working from a single Swift resource directory by default on non-Darwin/Windows platforms, because it annoyed me that each runtime architecture in a bundle would require a separate resource directory, even though the approach I used was ultimately rejected by the Swift devs. I hope someone works on the alternate approach suggested by them, and we get this fixed.