Nuke cannot be built with Carthage 0.37.0 due to NukeDemo causing an infinite loop

[1oo7]

On Carthage 0.37.0, building Nuke always fails with timeout.

This is because Carthage builds all projects in a repo, and Nuke's repo includes NukeDemo, which in turn has the following four remote Swift Package dependencies:

• Alamofire
• SwiftSVG
• Gifu
• Nuke

Cloning each of those repos requires over 2 minutes on my laptop with gigabit fiber ethernet. Here is the result of those repos getting cloned and then checked out:

Subsequent carthage bootstrap operations result in Carthage building each of the Xcode projects found nested in the Alamofire/, SwiftSVG/, Gifu/, and Nuke/ subdirectories of Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/. Since that Nuke directory also contains a copy of the NukeDemo project, these subsequent carthage bootstrap operations result in an ongoing infinite loop of building NukeDemo and all its dependency projects, punctuated only by timeout errors when Carthage eventually gives up.

Here is a detailed analysis over time of the events that occur during the first carthage bootstrap operation, with timestamps:

1. [16:43:42] ran carthage bootstrap --use-ssh --no-use-binaries --platform iOS --configuration Release --cache-builds --new-resolver
2. [16:44:51] Carthage begins cloning Nuke into Carthage/Checkouts/Nuke
3. [16:46:15] Carthage begins building Carthage/Checkouts/Nuke/Nuke.xcproj
4. [16:46:23] Carthage begins building Carthage/Checkouts/Nuke/Demo/NukeDemo.xcproj
5. [16:46:24] SPM begins cloning Nuke into Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/repositories/Nuke-8db81083
6. [16:46:32] SPM begins cloning Gifu into Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/repositories/Gifu-05fd1ae0
7. [16:47:53] SPM begins cloning SwiftSVG into Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/repositories/SwiftSVG-ae27d62c1
8. [16:48:11] SPM begins cloning Alamofire into Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/repositories/Alamofire-11b78eba
9. [16:49:13-14] SPM creates subdirectories and checks out these repos into Nuke/, Gifu/, SwiftSVG/, and Alamofire/ in Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/
10. [16:49:15] carthage boostrap operation fails with error: xcodebuild timed out while trying to read NukeDemo.xcodeproj 😭

And here is the subsequent carthage bootstrap operation:

10. [16:52:01] ran carthage bootstrap --use-ssh --no-use-binaries --platform iOS --configuration Release --cache-builds --new-resolver
11. [16:53:15] Carthage begins trying to build Nuke again, picking up where it left off in step 9. above.
12. [16:53:48] Carthage begins building Alamofire in Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/Alamofire/Alamofire.xcproj
13. [16:54:00] Carthage begins building SwiftSVG in Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/SwiftSVG/SwiftSVG.xcproj
14. [16:54:05] Carthage begins building Gifu in Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/Gifu/Gifu.xcproj
15. [16:54:09] Carthage begins building Nuke in Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/Nuke/Nuke.xcproj
16. [16:54:26] Carthage begins building NukeDemo in Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/Nuke/Demo/NukeDemo.xcproj
17. [16:54:30] SPM begins cloning Nuke into Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/repositories/Nuke-8db81083
18. [16:54:38] SPM begins cloning Gifu intoCarthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/repositories/Gifu-05fd1ae0
19. [16:55:51] SPM begins cloning SwiftSVG into Carthage/Checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/Nuke/Demo/DerivedData/NukeDemo/SourcePackages/repositories/SwiftSVG-ae27d62c1
20. [16:57:21] carthage boostrap operation fails with error: xcodebuild timed out while trying to read NukeDemo.xcodeproj 😭

If I run carthage boostrap again, guess what happens?

The infinite cycle continues.

Each time carthage bootstrap gets run after this, Carthage adds another nested build of NukeDemo, SPM clones all its SPM dependencies (including Nuke!), and Carthage builds those, which results in the further nested NukeDemo getting built, all its SPM dependencies getting cloned, etc. until timeout and 😭.

I.e., we will end up with:

Carthage/Checkouts/
Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/
Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/
Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/
Nuke/Demo/DerivedData/NukeDemo/SourcePackages/checkouts/
...etc. forever.

But why does Carthage build both Nuke.xcproj and NukeDemo.xcproj, in the first place? Shouldn't Carthage ignore other projects that are nested in subfolders?

Well, I looked into this question, and I learned the following information:

• Carthage is designed to build all the .xcproj's in each dependency repo. This is how it is intended to work. (RxSwift issue 34, which was fixed in RxSwift PR 35; Carthage issue 1974, particularly this comment)
• Carthage building NukeDemo is therefore not a bug, and is not due to anything peculiar to my local setup.
• Carthage building the things inside Nuke/Demo/DerivedData/NukeDemo/

This comment from Carthage issue 1974 mentions that "Carthage always prefers to build through a workspace," making it sound like adding an .xcworkspace that only contains Nuke (but not NukeDemo) could be a possible solution. However, I tried this, and the problem still happens. So that's not a workable solution.

Interestingly, I found an older thread from 2014 where someone had made this comment:

Carthage only finds and builds a single project. If that weren't the case, it would erroneously pick up dependency/example/demo projects, which is rarely what one wants.
I think the current behavior is reasonable.

... and this comment:

Carthage finds the root-most project and builds that. So it expects to find one framework project, and ignores all others (some of which might include examples/demos, dependencies, etc.). This results in the best behavior in ≥ 80% of cases.
So, if you have multiple framework projects, the correct solution is to combine them into one, and use targets and schemes to separate builds—not projects.

So.. it seems at some point that Carthage's developers decided "the current behavior is reasonable" was wrong, and that it was better to "erroneously pick up dependency/example/demo projects" than to just build the root project of a repo. Perhaps for some projects that's fine, but obviously for projects like Nuke, which have a nested demo project that depends on the parent project as a remote SPM dependency, that can cause an infinite loop causing Carthage to always fail.

Perhaps the old wisdom of only building the root project was much better, however I doubt Carthage's current maintainers will want to reverse course on this, since it would probably break something else.

The current workaround we're using for our app to pass CI, is to run carthage checkout, then rm -rf Carthage/Checkouts/Nuke/Demo, then carthage build.

But I would humbly ask that, until Carthage gets updated to address this problem, could you please separate out Nuke Demo into its own, separate repository, so that we can just build Nuke without having an infinite loop? Thanks!

[kean]

Thanks for the details write-up, I appreciate it. Is switching to Swift Package Manager a viable option for you? I was planning to remove Carthage support soon anyway. You can use https://github.com/marketplace/actions/swift-create-xcframework to compile Nuke as an XCFramework, it should be relatively easy. I'm also planning to start adding binary frameworks with new releases.

[1oo7]

Is switching to Swift Package Manager a viable option for you? I was planning to remove Carthage support soon anyway.

No, we just forked Nuke on our internal repo, and deleted NukeDemo from the project.

SwiftPackageManager is not a viable solution for us yet, there are far too many bugs with it. I've currently got six open bug tickets with Apple to address all these issues.

Probably the biggest blocker for us to use SPM is how it handles caches. It stores repositories, checkouts, and builds of third-party dependencies inside the DerivedData folder. Xcode 12.5 added the ability to have a per-user repo cache, which greatly speeds up subsequent builds. But the first time it has to check out a repo, it does a deep-clone, which can take a very long time.

I suggested to Apple that they shoudl only do a shallow clone for the initial checkout, but I think github has some restrictions around shallow clones now, since updating a shallow clone tends to require quite a few calls to the github APIs. Homebrew recently had to migrate to using a deep clone as well, for exactly that reason.

Even if the clones were quick, there are several other things that have really been blocking us from using SPM as a replacement for Carthage.

Carthage makes it very easy for us to not only build XCFrameworks of all our dependencies, but also, it lets us inject an .xcconfig file into the build arguments so we can override certain build settings in our dependency repos. (There may be a similar capability in SPM, but if so I haven't found it—and it seems that Swift packages build when you build your app.)

Another issue is that we already have a cacheing solution for Carthage, namely Rome. The fact that Carthage uses directories that are independent of DerivedData means that you can delete DerivedData without having to re-bootstrap your third-party dependencies.

We also don't like the fact that with SPM, when you open the project, it has to resolve all the source dependencies. Whereas with Carthage, Xcode doesn't know or care about the source-code in our Carthage/Checkouts.

There are a bunch of other reasons we are holding off on packages yet:

Issues related to linking external frameworks to a Swift Package NOT using .binaryTarget:
- Having to resort to unsafe flags with frameworks: https://forums.swift.org/t/override-for-unsafeflags-in-swift-package-manager/45273
- Main Q&A thread on using unsafe flags to link frameworks, with the google firebase guy: https://forums.swift.org/t/binary-frameworks-with-swiftpm/26225/18
- Old file-specific build options where people talked about, some of which never got implemented https://forums.swift.org/t/file-specific-build-options-in-swiftpm/26723/4
- Confused by unsafe flags being disallowed in dependencies - Development / Package Manager - Swift Forums

Issues related to .binaryTarget
- Bugs and issues using .binaryTarget XCFramework: https://forums.swift.org/t/use-xcodebuild-swift-package-with-binarytarget-logic-flaw/41579/10
- Question I posted that never got answered yet, How can local Swift packages' dynamic library targets dynamically link to local XCFrameworks that are in the Carthage/Build directory—without causing Xcode to synthesize any copy-frameworks steps for the linked XCFramework—and without causing Xcode to build and place static versions of any of these dynamic libraries into $(BUILT_PRODUCTS_DIR)/Frameworks? https://forums.swift.org/t/question-about-swift-packages/45231
- Thread I started that never got replies, about the .binaryTarget issues: https://forums.swift.org/t/bug-with-binarytarget-in-swift-packages-with-xcode/45191/2
-

Issues related to weak linking:
- Why Swift Package Manager does not support weak linking (-weak_framework SwiftUI) - Using Swift - Swift Forums

Issues related to headers:
- Cannot create a Package using binary resources with modulemap - Using Swift - Swift Forums

Issues related to dynamic library package targets being treated as static:
- "Unexpected Duplicate Tasks" bug, predominant in 12.5. https://forums.swift.org/t/swift-package-with-resources-in-ios-project-wont-compile-test-targets/40846 Update: evolved into a discussion of a workaround involving my trick with unsafe flags. [Link]
- "Swift package target 'A' is linked as a static library by 'C' and 'A-stub'. This will result in duplication of library code" i.e. Bug where dynamic libraries declared in the same package, link statically instead of dynamically https://forums.swift.org/t/swift-packages-in-multiple-targets-results-in-this-will-result-in-duplication-of-library-code-errors/34892/8
⁃ initial workaround was DISABLE_DIAMOND_PROBLEM_DIAGNOSTIC=YES
⁃ but DTS told me another solution (see those emails)
⁃ Users say this makes SPM useless with Xcode
- Open question as to whether 12.5 actually fixes this: Xcode 12.5 and automatic dynamic linking of products - Development / Package Manager - Swift Forums

Issues related to both the static linking thing and XCFrameworks:

[kean]

Right, yeah, I think I can move the demo. It will make SPM checkouts a bit faster too.

[1oo7]

Hopefully it's just temporary. I also filed this bug with Carthage: Carthage/Carthage#3148

I don't understand why they are building something else besides the main project in the root directory.

Someone else has a PR up to Carthage that would allow the user to skip certain schemes. I suggested to them that they consider possibly also allowing for ignoring certain folders or certain projects based on a filename regex (or whatever).

Because in my view, you should not have to remove NukeDemo from your project, and I see no reason why Carthage should try to build it as part of the process.

See my comments on that thread.

[kean]

Fixed in Nuke 9.3.1.

That's alright, I'm happy to move it as it should also slightly improve the checkout speed for other package managers.

[1oo7]

THANK YOU!