Switching to swiftResourcesPath broke building an SDK directly from Debian packages
#141
Assignees
Comments
This was referenced Nov 1, 2024
euanh
added a commit
that referenced
this issue
Nov 11, 2024
…m CI (#144) Building an SDK requires running the sdk-generator with `swift run swift-sdk-generator`. This takes a lock on `.build`, but if the tests are being run by `swift test` the outer Swift Package Manager instance will already hold this lock, causing the test to deadlock. We can avoid this by giving the `swift run swift-sdk-generator` instance its own scratch directory. This PR consolidates the code which builds SDKs in one function, then runs each SDK build with its own temporary scratch directory. This avoids the deadlock on the `.build` directory when run under `swift test`. The tests continue to pass when run under Xcode, which was not affected by the deadlock because it works in a separate scratch directory. :warning: **The tests cannot currently run in CI because SDK generator cannot use the HTTP proxy to download packages.** This PR allows the tests to be run locally with `swift test` but skips them when running in the CI. When the downloading problem is solved, the tests can be enabled in CI as well. :warning: RHEL-based Swift 6.0 SDKs built from container images currently do not currently work, as reported in #138. This PR makes it possible to run the test locally under `swift test` while working on this problem, to prevent regressions such as #141. Fixes #143
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
.xctoolchaindirectory in the SDK bundle. Previously, the compiler found those files, but theswiftResourcesPath/swiftStaticResourcesPathconfiguration options causes it to look only in the.sdkdirectory, 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
.xctoolchaindirectory. 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.The text was updated successfully, but these errors were encountered: