Pitch: Cross-Compilation Destination Bundles

[stevapple (YR Chen)]

Overall +1 for the pitch! It would be great to have such “Swift SDKs” for cross compilation.

Some instant thoughts:

@Max_Desiatov

swift destination install <bundle URL or local filesystem path>, which downloads a given bundle if needed and installs it in a location discoverable by SwiftPM. For destinations installed from remote URLs an additional --checksum option is required, through which users of destinations can specify a checksum provided by publishers of destinations. The latter can produce a checksum by running swift package compute-checksum command (introduced in SE-0272) with the destination artifact bundle archive as an argument.

I would like to see destination bundles available from registries, which could make use of the proposed authentication system and identifier design. This should be natural for internal distribution.

@Max_Desiatov

As an example, destination publishers looking to add a library to an Ubuntu 22.04 destination environment would modify a Dockerfile similar to this one in CC destination generator source code:

FROM swift:5.7-jammy

apt-get install -y \
  # PostgreSQL library provided as an example.
  libpq-dev
  # Add more libraries as arguments to `apt-get install`.

While it’s a valid use case, I don’t think we should ask anyone who only wants an additional library to do so… As @Karl pointed out, we should explore some way to “extend” a CC destination bundle, something like the FROM keyword in Dockerfile.

@Max_Desiatov

CC Destination Artifact Bundles

As a quick reminder for a concept introduced in SE-0305 , an artifact bundle is a directory that has the filename suffix .artifactbundle and has a predefined structure with .json manifest files provided as metadata.

Reusing the artifact bundle design is okay for me, but I'm wondering if a CC destination really is, by definition, an “artifact” for SwiftPM and its users. Maybe we should use just a different file extension — and maybe we should do so for the plugins.

@Max_Desiatov

Another issue related to SourceKit-LSP is that it always build and indexes source code for the host platform. Ideally, we want it to maintain indices for multiple platforms at the same time. Users should be able to select to target platforms and corresponding indices to enable semantic syntax highlighting, auto-complete, and other features for areas of code that are conditionally compiled with #if directives.

This is, IMO, already a big problem for cross-platform developers (and tool authors!) even without extended destination support. SourceKit-LSP basically has no knowledge of “destination”. I believe the two sides of work are decoupled at least for now.