Add support for building Swift SDKs for armv7 with target Swift toolchain or docker container #170
Conversation
- If it's not there, it's likely that the toolchain did not come with clang included and that is okay.
|
@swift-ci test |
|
Right now if I do something like this: $ swift run swift-sdk-generator make-linux-sdk --swift-version 6.0.3-RELEASE --host x86_64-unknown-linux-gnu --target armv7-unknown-linux-gnueabihf --linu
x-distribution-name rhel --with-dockerI just get a Docker error, which of course means there is no container available for rhel-ubi9 for armv7: Launching a Docker container to copy Swift SDK for the target triple from it...
Error: process exited non-zero: exit(125)So perhaps this situation can be detected up front, and we can throw an error saying that RHEL UBI9 does not support armv7. What do you think @MaxDesiatov ? |
Yes, that's what I was referring to in the other thread. If we know that generation for other armv7 distributions can't possibly work and we can detect that early, we should log an error message. Or if it could possibly work, but we don't know for sure, then at least a warning message saying this codepath is not fully supported. |
…ting to create a Swift SDK with rhel for armv7
|
@MaxDesiatov RHEL and Fedora do not support armv7 and there don't appear to be any plans to support it any more in the future:
So, I've opted to add a new
There really is no way this configuration would work unless someone in a corner of the galaxy is compiling and running RHEL for armv7 for some reason. |
|
@swift-ci test |
|
@euanh @kateinoigakukun do you guys have a minute to check out this PR this week? The changes are pretty minor I think, and work well as long as you've got build artifacts, so it could be good to have in the generator while I continue working on updating swiftlang/swift to be able to cross-compile for armv7. |
|
@swift-ci test |
…r/swift-sdk-generator into swiftlang#65-support-armv7
|
@swift-ci test |
…sed SDK PR swiftlang#177 was intended to skip unnecessary toolchain downloads, making it possible to build a container-based SDK offline if all its requirements had already been dowloaded. The change was too broad and also broke building package-based SDKs. PR swiftlang#177 skips calling generator.downloadArtifacts() when building an SDK without an embedded host toolchain (the default). In addition to downloading the host toolchain (and LLVM, if needed), generator.downloadArtifacts() is also responsible for downloading the target toolchain. This is not needed when building a container-based SDK but is required when building a package-based SDK, which combines an SDK from swift.org with supporting libraries extracted from Debian packages. In fact, generator.downloadArtifacts() already avoids downloading toolchains when building a container-based SDK without an embedded toolchain. The only network call which caused offline builds to fail was an unconditional check for a suitable LLVM binary from GitHub. This PR restores the call to generator.downloadArtifacts() and only makes the LLVM check if LLVM is in the list of required downloads. This allows the EndToEnd tests to pass again (with PR swiftlang#170 temporarily reverted because of issue swiftlang#181).
…sed SDK (#182) PR #177 was intended to skip unnecessary toolchain downloads, making it possible to build a container-based SDK offline if all its requirements had already been dowloaded. The change was too broad and also broke building package-based SDKs. PR #177 skips calling generator.downloadArtifacts() when building an SDK without an embedded host toolchain (the default). In addition to downloading the host toolchain (and LLVM, if needed), generator.downloadArtifacts() is also responsible for downloading the target toolchain. This is not needed when building a container-based SDK but is required when building a package-based SDK, which combines an SDK from swift.org with supporting libraries extracted from Debian packages. In fact, generator.downloadArtifacts() already avoids downloading toolchains when building a container-based SDK without an embedded toolchain. The only network call which caused offline builds to fail was an unconditional check for a suitable LLVM binary from GitHub. This PR restores the call to generator.downloadArtifacts() and only makes the LLVM check if LLVM is in the list of required downloads. This allows the EndToEnd tests to pass again (with PR #170 temporarily reverted because of issue #181).
…ft toolchain or a container (swiftlang#170)" This reverts commit d4aba13.
This would implement #65. Although there is no official support for armv7 in Swift yet, this opens the door for being able to generate Swift SDKs for cross compilation to armv7 given you have build artifacts to give it. In my case, I can grab some that I built from my swift-armv7 repo, download and extract, then run the generator like this:
And, this generates a working Swift SDK that I can use to cross compile anything, like a Hummingbird app:
So, I think that it could be reasonable to add this support to the generator now. It's something I will use myself, but also when official support for armv7 lands for Swift, it'll be ready ;)