xcodebuild indeterminately fails to compile Nimble on tvOS test target

[loudmouth]

• I have read CONTRIBUTING and have done my best to follow them.

What did you do?

In running tests on TravisCI with xcodebuild, my project is failing to compile more often than not on tvOS causing my builds to fail. After investigating locally by running my tvOS test xcodebuild command, I've identified that it is Nimble that is failing to compile. While xcodebuild fails, building and testing in the actual Xcode application always succeeds.

Note: I am using carthage to manage Nimble as a git submodule via carthage update --use-submodules --no-build; i.e. I have the Carthage/Checkouts directory checked into source control and the Nimble.xcodeproj is included in my Xcode workspace.

What did you expect to happen?

I expected the Nimble target to compile determinately, i.e. 100% of the time.

What actually happened instead?

When running my tvOS test command locally with xcodebuild (and without xcpretty pretty-formatting the output), the compilation errors that are printed look as follow:

        Use of undeclared type 'request_mach_exception_raise_t'
        Use of undeclared type 'reply_mach_exception_raise_state_t'
        Use of unresolved identifier 'request_mach_exception_raise_t'; did you mean '__Request__exception_raise_t'?
        Use of unresolved identifier 'reply_mach_exception_raise_state_t'; did you mean '__Reply__exception_raise_state_t'?
        Use of undeclared type 'request_mach_exception_raise_t'
        Use of undeclared type 'reply_mach_exception_raise_state_t'
        Use of unresolved identifier 'mach_exc_server'; did you mean 'mach_msg_server'?
        'thread_swap_exception_ports' is unavailable
        'thread_swap_exception_ports' is unavailable
        Use of unresolved identifier 'catchExceptionOfKind'
        Use of unresolved identifier 'bad_instruction_exception_reply_t'
        Testing cancelled because the build failed.

I've noticed that if I clean my derived data folder then run, the build is more likely to succeed, but any subsequent build, presumably using some build cache, fails.

Environment

List the software versions you're using:

• Nimble: 7.3.1
• Xcode Version: 10.1 (10B61)
• xcodebuild: 10.1 (10B61)
• Swift Version: 4.2

Please also mention which package manager you used and its version. Delete the
other package managers in this list:

• Carthage: 0.31.2 — I manage git submodules with carthage with the --use-submodules option

Project that demonstrates the issue

Contentful Swift SDK

Simply clone project, cd into it, run git submodule update --init --recursive, then you are ready to run the test command:

xcodebuild test -workspace Contentful.xcworkspace -scheme Contentful_tvOS -sdk appletvsimulator -destination 'platform=tvOS Simulator,name=Apple TV,OS=12.1' ONLY_ACTIVE_ARCH=YES CODE_SIGNING_IDENTITY= CODE_SIGNING_REQUIRED=NO

[loudmouth]

Some additional notes:

I did try to "debug" this on my own but couldn't figure it out. I had assumed that there was a file missing from the Nimble-tvOS target in Xcode from one of the Cwl... dependencies that Nimble rely's upon.

I also tried using the latest version of Nimble at the HEAD of master and it did not solve the issue.

Lastly, I should note that this issue only started appearing on Xcode 10 and was not present on Xcode 9.x

[loudmouth]

Any chance anybody has had a chance to investigate this? On TravisCI I'm having to restart my tvOS builds until I'm lucky enough for them to pass...sometimes taking up to 6 tries 😢

[loudmouth]

Unfortunately, this was such a big time-sink for me that i had to go ahead and prune Nimble from my project and replace all assertions with standard XCTest assertions. I will leave this issue open for now since I imagine the problem is still there, and leave it to the maintainers discretion whether or not to close it.

Since I left a link to my project as an example of this issue, I can at least point you to the last tag that had Nimble in it: https://github.com/contentful/contentful.swift/releases/tag/4.1.2

[younata]

Hey @loudmouth! I appreciate the issue!

Unfortunately, I'm unable to reproduce this. I'm hoping that means it's been fixed in the intervening 3.5 years since you opened it. I'm going to close it, feel free to reopen this if it's not actually fixed on the current release (9.3.1 as of this writing. I tested on Xcode 13.3.1, on an m1 max mac).