Can't run ParseLiveQuery built via Carthage

[JoeSzymanski]

I'm trying to do some testing of ParseLiveQuery, and I'm running into a problem integrating the framework in Xcode 8.

I'm using Carthage with ParseLiveQuery as the only dependency. ParseLiveQuery and the necessary dependencies appear to be built, and I can properly add them to my Xcode project and build. The problem occurs when I try to run the app. The app crashes immediately with the following error:

dyld: Library not loaded: @rpath/BoltsSwift.framework/BoltsSwift Referenced from: /Users/jszymanski/Library/Developer/CoreSimulator/Devices/66A77A5B-1C69-49FF-A3E8-887858A83CE5/data/Containers/Bundle/Application/10078C94-A621-4A5C-ADAA-6A1D5A2DDF0B/ParseTest.app/Frameworks/ParseLiveQuery.framework/ParseLiveQuery Reason: Incompatible library version: ParseLiveQuery requires version 1.0.0 or later, but BoltsSwift provides version 0.0.0

Does anyone have any idea how to get around this problem? I've tried manually integrating everything, but that has had all sorts of other problems. I'm trying to avoid going down the route of CocoaPods, due to how much additional overhead there is in place to get that built and working.

[flovilmart]

I've noticed that issue too, I'm not sure how to fix it.

[JoeSzymanski]

I have been digging, and I think the problem here is that ParseLiveQuery looks like it uses mostly pre-built binaries (where possible), and somehow, those have a dyld version and dyld compatibility version of 0, while the ParseLiveQuery binary somehow expects those to have versions of at least 1.

I've tried changing the carthage command to force everything to be built from source, and that results in build errors in one of the phases that should only be used for CocoaPods:

The following build commands failed:
PhaseScriptExecution [CP]\ Check\ Pods\ Manifest.lock /Users/jszymanski/Library/Developer/Xcode/DerivedData/ParseLiveQuery-ffrsytiiiarwbxgwnnhibvzrnwuh/Build/Intermediates/ParseLiveQuery.build/Release-iphoneos/ParseLiveQuery-iOS.build/Script-12BD489D413AD268FF85A8FA.sh
error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.

On top of this, I didn't think it was possible to ship binaries of Swift frameworks, which seems to run counter to the fact that this: https://forums.developer.apple.com/thread/66852
It looks like this repo should remove the binary artifacts for the framework to avoid running into problems like this, then figure out how to fix the build when running via Carthage.

[JoeSzymanski]

It's worth noting that, as far as I can tell, there is no support for building ParseLiveQuery in any way outside of CocoaPods. I can't even build the library manually, which I would expect to work.

[dstarke]

Fixing this requires major changes to the way the library is built. Currently, building this library can only be done using CocoaPods, which maintains a lot of the build mechanics. Without it (or on a fresh checkout), the build doesn't work. For example, CocoaPods maintains the build phase script which checks to make sure pod install has been run and fails the build otherwise. That script can't be altered or removed because it will be restored the next time that pod install runs.

It seems like other projects use a combination of Carthage and Git submodules to make the dependencies available, and configure the Xcode project or workspace to correctly build the project without any additional tool requirements.

The dependencies are already included in this project as Git submodules, so the main change would be to set up the project and workspace to build without using CocoaPods.

To give a sense of what this might look like, I've made an attempt at this in a branch on a fork:

universal-build branch of Workhood/ParseLiveQuery-iOS-OSX

I'm happy to submit this back as a pull request. We've tested this by building with Xcode, by building from the command line, and by including it as a dependency with Carthage, and it seems to work, but there may be other build situations that we haven't tried, and I haven't fixed the example projects to work under this new build strategy.

I realize this is a dramatic change to how things are built, but in the current state without such changes, given what Apple has said about binary compatibility for frameworks and apps built with different versions of the compiler, the only safe workaround is to manually integrate by copying this project's sources into your project and adding this project's dependencies as dependencies of your project.

[JoeSzymanski]

I think that kind of change is exactly what I was expecting needed to be done. A pull request is probably a good starting point for getting this build process fixed.

[flovilmart]

Odd thing is that a local build with carthage build --no-skip-current is functional.

[JoeSzymanski]

I'm not certain that the carthage build command actually builds the Xcode project if there are pre-built binaries available. I previously tried carthage update --no-use-binaries and was unable to get a functional build working.

[dstarke]

I think carthage build --no-skip-current would have worked if you had previously run a pod install in your development environment. And Carthage may have appeared to work from other projects if you didn't force it to not use binaries, but that's not safe for Swift-based libraries. It didn't work for me on a fresh checkout, and I had the same experience as @JoeSzymanski attempting to use it in a dependent project, since I was forcing --no-use-binaries. (I would not have figured out what was going on without this thread, so thank you!)

I'll issue a pull request for my changes. I do want to point out that it will change the development environment considerably for anyone who works on this project, as CocoaPods would no longer be used to build, and the Git submodules need to be kept up to date correctly. In addition, my changes break the example projects, which either need to be changed to not use CocoaPods, or updated to use CocoaPods in a self-contained way. I expected both of these issues to be sticking points for accepting a pull request.

[flovilmart]

, as CocoaPods would no longer be used to build, and the Git submodules need to be kept up to date correctly

I'm not sure that shift is really necessary, I'm confident we can have a simple build script that would yield a proper library.

[flovilmart]

I don't think the full overhaul is needed just because the bolts lib version is 0.0.0 instead of 1.0.0.

[JoeSzymanski]

@flovilmart The version number of bolts library is a symptom of the larger problem around using a pre-built library. Swift expressly forbids using pre-built binaries.

In addition, the library currently requires building via cocoapods, which means that the only way to integrate currently is also via cocoapods. Neither Carthage nor directly including the project as a dependent work without the full cocoapods integration being in place.

I think the best way to move forward is to try to remove the requirement of cocoapods at some point, since that puts some heavy limits on how the library can be integrated.

[flovilmart]

Swift expressly forbids using pre-built binaries.

not sure what you mean by that, we use them all the time through carthage and github releases.

Neither Carthage nor directly including the project as a dependent work without the full cocoapods integration being in place.

There is the Cartfile that should provide the dependencies, independent of cocoapods, Bolts is Carthage compatible.