Error: noCacheKeyConformance(Swift.Array<SystemPackage.FilePath.Component>) #106
Comments
|
Add code to end of file |
|
Great, thank you for investigating this. Now for the PR we need test coverage before it can be considered for merging. |
euanh
added a commit
to euanh/swift-sdk-generator
that referenced
this issue
Nov 13, 2024
This is needed to cache arrays of [FilePath.Component], so a subsequent commit can cache the slow extraction of the `ld.lld` binary from the `llvm` tar archive. This problem was also reported by @yingguqing in swiftlang#106, although Range conformance does not seem to be required to cache lld. Suggested-by: @yingguqing
euanh
added a commit
to euanh/swift-sdk-generator
that referenced
this issue
Nov 13, 2024
This is needed to cache arrays of [FilePath.Component], so a subsequent commit can cache the slow extraction of the `ld.lld` binary from the `llvm` tar archive. This problem was also reported by @yingguqing in swiftlang#106, although Range conformance does not seem to be required to cache lld. Suggested-by: @yingguqing
euanh
added a commit
that referenced
this issue
Nov 14, 2024
…hive (#149) Extracting `lld` from the `llvm` archive takes about 40s on my machine, and after the binary has been extracted a 5.5GB directory is left behind in the `Artifacts` directory. This change uses `tar` filters to reduce the number of files unpacked from the archive and caches the resulting `lld` binary. Excluding the time to download the archives, building an SDK from Debian packages before `lld` has been cached takes about 57s on an M3 MacBook Air. A subsequent build with `lld` cached takes about 17s. The SDKs generated by the old and new methods are identical. This PR adds `CacheKey` conformance to `Array`, as suggested by @yingguqing in #106. Adding this conformance to `Range` was not necessary in this case. -- * generator: Adopt CacheKey conformance for [FilePath.Component] This is needed to cache arrays of [FilePath.Component], so a subsequent commit can cache the slow extraction of the `ld.lld` binary from the `llvm` tar archive. This problem was also reported by @yingguqing in #106, although Range conformance does not seem to be required to cache lld. Suggested-by: @yingguqing * generator: Cache the lld binary after extracting it from the LLVM archive Extracting `lld` from the `llvm` archive takes about 40s on my machine, and after the binary has been extracted a 5.5GB directory is left in the `Artifacts` directory. This change uses `tar` filters to reduce the number of files unpacked from the archive and caches the resulting `lld` binary. Excluding the time to download the archives, building an SDK from Debian packages before `lld` has been cached takes about 57s on an M3 MacBook Air. A subsequent build with `lld` cached takes about 17s. The SDKs generated by the old and new methods are identical.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi! I am trying to cross compile for ubuntu
x86_64andarm64architectures. I followed the steps on the readme and cloned the repo and ranswift run swift-sdk-generator make-linux-sdk.However, I am seeing this output:
Edit: And running again with verbose output:
Curious if this is an issue or if I am doing something wrong. I am running this on an M1 Pro Mac on macOS Sonoma with swift 5.9.
Output of
uname -a:Darwin <local host>.local 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:52 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T8103 x86_64Output of
swift --version:SHA of swift-sdk-generator:
db85e25Thanks!
The text was updated successfully, but these errors were encountered: