Remove Cartfile

[soffes]

We don't actually need this because Xcode uses SPM to get these deps. Specifying the Cartfile causes Carthage to get the dependencies, but Xcode will fetch and use the SPM dependencies instead.

@eliperkins and I spent a long time trying to debug why changing the version of something in the Cartfile in our fork wasn't working and then we realized it was this issue.

[apollo-cla]

@soffes: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

[designatednerd]

I'm somewhat confused by this - doesn't Carthage need to know about the dependencies in order to build them? Or are you saying that Carthage will see the dependencies fetched by SPM?

[eliperkins]

doesn't Carthage need to know about the dependencies in order to build them? Or are you saying that Carthage will see the dependencies fetched by SPM?

Since Apollo.framework, as defined within the Apollo.xcodeproj, uses SPM to manage it's own dependencies, Carthage has nothing to do here.

Since Carthage will invoke xcodebuild -scheme Apollo, the result is that Xcode will run SPM (or some form of swift package resolve), and then pull these dependencies in, linking statically via SPM!

Here's a snippet of the build logs for carthage build --no-skip-current for Apollo:

/usr/bin/xcrun xcodebuild -project /Users/eliperkins/src/apollo-ios/Apollo.xcodeproj -scheme Apollo -configuration Release -sdk appletvos ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath /var/folders/v0/4yqzqdxd6j13p6kl5c8qwlhh0000gn/T/apollo-ios SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO (launched in /Users/eliperkins/src/apollo-ios)Command line invocation:
    /Applications/Xcode12.0b2.app/Contents/Developer/usr/bin/xcodebuild -project /Users/eliperkins/src/apollo-ios/Apollo.xcodeproj -scheme Apollo -configuration Release -sdk appletvos ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES archive -archivePath /var/folders/v0/4yqzqdxd6j13p6kl5c8qwlhh0000gn/T/apollo-ios SKIP_INSTALL=YES GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=NO CLANG_ENABLE_CODE_COVERAGE=NO STRIP_INSTALLED_PRODUCT=NO

User defaults from command line:
    IDEArchivePathOverride = /var/folders/v0/4yqzqdxd6j13p6kl5c8qwlhh0000gn/T/apollo-ios

Build settings from command line:
    CARTHAGE = YES
    CLANG_ENABLE_CODE_COVERAGE = NO
    CODE_SIGN_IDENTITY =
    CODE_SIGNING_REQUIRED = NO
    GCC_INSTRUMENT_PROGRAM_FLOW_ARCS = NO
    ONLY_ACTIVE_ARCH = NO
    SDKROOT = appletvos14.0
    SKIP_INSTALL = YES
    STRIP_INSTALLED_PRODUCT = NO

Resolve Package Graph

Resolved source packages:
  PathKit: https://github.com/kylef/PathKit.git @ 0.9.2
  Stencil: https://github.com/stencilproject/Stencil.git @ 0.13.1
  Spectre: https://github.com/kylef/Spectre.git @ 0.9.0
  Starscream: https://github.com/daltoniam/Starscream.git @ 3.1.1
  SQLite.swift: https://github.com/stephencelis/SQLite.swift.git @ 0.12.2
  swift-nio-zlib-support: https://github.com/apple/swift-nio-zlib-support.git @ 1.0.0

By including this Cartfile within the repo, Carthage thinks that it needs to manage all the dependencies within the Cartfile for Apollo, and thus, we end up with two sets of the dependencies: statically linked ones from SPM within Xcode, and dynamically linked ones from Carthage.

Since Carthage is gonna invoke xcodebuild and SPM will do the work to link these libraries, I think it's safe to not tell Carthage about these dependencies.

[eliperkins]

Oh! Another bit of evidence that we found related to this:

We forked SQLite.swift to get around some funky build errors with it we were seeing related to it's usage within our project, and completely removed any and all symbols related to SQLiteObjc within our fork.

When pointing Carthage at this fork of the dependency, we still encountered that SQLiteObjc existed as a string within our built artifacts:

❯ strings Carthage/Build/iOS/ApolloSQLite.framework/ApolloSQLite | grep SQLiteObjc
/Users/eliperkins/Library/Caches/org.carthage.CarthageKit/DerivedData/11.5_11N605c/apollo-ios/b63ba582019d75faa1bbc664f523571ffaf29487/SourcePackages/checkouts/SQLite.swift/Sources/SQLiteObjc/SQLiteObjc.m

Even though we had pointed Carthage at our fork of the project. This turned out to be because ApolloSQLite.framework pulled in this dependency via SPM completely outside of Carthage!

[designatednerd]

Aha! Thank you for the thorough explanation, that makes a lot more sense now.

[designatednerd]

Not sure why circle never ran on this but I'm gonna let it slide since theoretically this file is unnecessary anyway 🙃

[soffes]

Thanks everyone ❤️

[teodorpenkov]

Is this related to this issue here #1205

[eliperkins]

@teodorpenkov I don't believe so. We encountered the "missing module" issue with SQLite.swift outside of the context of Apollo as well.

[teodorpenkov]

Any ideas why is this happening? I've spent a good amount of hours trying to find the root cause without success.
What bothers me it's sometimes it's working and sometimes it's not 🤷‍♂️

[designatednerd]

@teodorpenkov I have found it to work WAY more consistently after updating to the newest version of carthage that came out a few weeks ago.

But yeah prior to that it was a complete crapshoot as to whether it would work and I constantly wanted to throw my laptop in the lake

[teodorpenkov]

Any plans to release Apollo version without this Cartfile?

I tried pinning apollo to a commit where this Cartfile is removed and then added SQLite.swift as an explicit dependency, it builded successfully 5 out of 5 times, which never happened before.

I'm currently at 0.28.0 and it doesn't matter if I add SQLite.swift as an explicit or leave it transitive dependency, it breaks at least 50% of the time. This happens with carthage 0.34.0 or 0.35.0.

[designatednerd]

Yes - was planning to bundle a couple other things into the release since it'll need to be a a major, though. In the meantime, you can point your Cartfile at the main branch of this repo and it'll work. Here's their doc with examples on how to set this up