[SR-14567] Binary targets non-deterministically fail to import in Xcode #4431
Comments
|
Update: I was able to reproduce this with the library declared as .static as well |
|
@swift-ci create |
|
As of Xcode 13.0b1 (13A5154h) using a tag with .revision doesn't seem to be working anymore, but upon replacing it with a commit hash I was able to reproduce this issue. |
|
The Xcode 13.0b3 release notes indicate that this has been resolved, but I can still reproduce the issue using the sample project that I provided. |
|
Comment by Johannes Hubert (JIRA) Here https://github.com/quentinfasquel/MyDependencySample 39 is another example project with the same problem. For me the error is deterministic and happens on every clean build. theindigamer (JIRA User) is there anything else we can do to help solve this problem? |
|
It's worth mentioning a couple of Swift Forums threads that provide additional information on (variations of) this bug: |
|
Comment by Artem Kirienko (JIRA) Doesn't look like a medium priority for me. It messes up our CI. The case when a binary dependency referenced by another dependency doesn't look so exotic. Could you bump the priority, please? Another relevant reference: https://forums.swift.org/t/bug-incorrect-dependency-build-order-in-spm/42290 |
Attachment: Download
Environment
macOS 11.2.3 (20D91), Xcode 12.5 (12E262), Swift 5.4, iOS SDK
Additional Detail from JIRA
md5: c8b4592640abaff404aa9df5bc296e78
Issue Description:
The following dependency graph causes non-deterministic build failures:
Xcode app -> MyProduct (dynamic library in MyPackage) -> MyTarget (Swift target in MyPackage) -> CMyTarget (C target in MyPackage) -> Binary target
In particular, CMyTarget occasionally fails to import the headers from the binary target. From my testing, this appears to be a race condition where the binary target's framework is not always extracted into the products directory before the C files using it are compiled.
I've attached a sample project demonstrating the bug (simply an iOS app with the aforementioned dependency graph). The issue only occurs on clean builds, and that too not always; quitting and re-opening Xcode also helps reproduce the bug. Re-building seems to fix the problem (because the framework is already in the products dir?), but that's unfortunately impractical for CI/CD setups.
The text was updated successfully, but these errors were encountered: