Change #139, which fixes building Swift 6.0 SDKs from containers, breaks building SDKs from Debian packages.
I discovered this while trying to get the EndToEnd tests running on macOS, as discussed in #139! 😢
% swift build --swift-sdk 5.10.1-RELEASE_ubuntu_jammy_aarch64
<unknown>:0: error: unable to load standard library for target 'aarch64-unknown-linux-gnu'
<unknown>:0: error: unable to load standard library for target 'aarch64-unknown-linux-gnu'
error: fatalError
Currently we copy some SDK files into the .xctoolchain directory in the SDK bundle. Previously, the compiler found those files, but the swiftResourcesPath/swiftStaticResourcesPath configuration options causes it to look only in the .sdk directory, and the set of files we put there when building from Debian packages is not quite sufficient.
I don't think we should rely on adding files to the .xctoolchain directory. The static Linux SDK doesn't include a toolchain at all (it has a vestigial, empty .xctoolchain/bin), and a glib-based SDK built from a container can also build these additional files (this also suggests we could build glib SDKs without embedded toolchains, similar to the static Linux SDK).
It should also be possible to build an SDK from Debian-packages without putting files in .xctoolchain, but the files we unpack from .debs are much more limited than the files we copy from containers, so a bit more work is required.
Change #139, which fixes building Swift 6.0 SDKs from containers, breaks building SDKs from Debian packages. I discovered this while trying to get the EndToEnd tests running on macOS, as discussed in #139! 😢
Currently we copy some SDK files into the
.xctoolchain
directory in the SDK bundle. Previously, the compiler found those files, but theswiftResourcesPath
/swiftStaticResourcesPath
configuration options causes it to look only in the.sdk
directory, and the set of files we put there when building from Debian packages is not quite sufficient.I don't think we should rely on adding files to the
.xctoolchain
directory. The static Linux SDK doesn't include a toolchain at all (it has a vestigial, empty.xctoolchain/bin
), and a glib-based SDK built from a container can also build these additional files (this also suggests we could build glib SDKs without embedded toolchains, similar to the static Linux SDK).It should also be possible to build an SDK from Debian-packages without putting files in
.xctoolchain
, but the files we unpack from.deb
s are much more limited than the files we copy from containers, so a bit more work is required.