search

parse-community / ParseLiveQuery-iOS-OSX

Parse LiveQuery Client for iOS/OS X.
https://parseplatform.org
Other
192 stars 133 forks source link

Updating build in preparation for iOS 13 update. #210

Closed noobs2ninjas closed 5 years ago

noobs2ninjas commented 5 years ago

This contains changes for issue #194 and is preparation for issue #209.

noobs2ninjas commented 5 years ago

Finally! After SEVERAL HOURS I found out the whole reason nothing worked is because the latest version of Jazzy 0.11.0 is broken and xcodebuild_arguments doesnt work. Anyway, this is finally passing and should be everything we need to build for xcode 11/iOS 13

noobs2ninjas commented 5 years ago

Only test that failed was the CircleCI macOS build. The reason /Users/distiller/project/Carthage/Checkouts/Bolts-ObjC/Bolts/iOS/BFWebViewAppLinkResolver.m:11:9: 'UIKit/UIKit.h' file not found. Why the heck is Bolts for iOS building on the macOS target?

drdaz commented 5 years ago

It might have something to do with this:

Multiple targets match implicit dependency for product reference 'BoltsSwift.framework'. Consider adding an explicit dependency on the intended target to resolve this ambiguity. (in target 'ParseLiveQuery-OSX' from project 'ParseLiveQuery')

Multiple targets match implicit dependency for product reference 'Parse.framework'. Consider adding an explicit dependency on the intended target to resolve this ambiguity. (in target 'ParseLiveQuery-OSX' from project 'ParseLiveQuery')

Multiple targets match implicit dependency for product reference 'Bolts.framework'. Consider adding an explicit dependency on the intended target to resolve this ambiguity. (in target 'Parse-iOS-Dynamic' from project 'Parse')

Is this new behaviour?

drdaz commented 5 years ago

It is new behaviour. It looks like it starts with this commit: https://github.com/parse-community/ParseLiveQuery-iOS-OSX/commit/7c4b806039421f51f02e9b31aba0e661e9d9808d

noobs2ninjas commented 5 years ago

I dont even know where to begin on this. You see anything in the file changes that could have even remotely changed how macOS got built?

noobs2ninjas commented 5 years ago

I realized that this might be an issue with Xcode and the carthage submodule. This then reminded me that I didnt update this to swift 5.0 because there was conflicts between starscream, facebook, and parse somehow. Anyway if my updates are correct circleci should now build and travis will fail because 1.17.3 isnt actually deployed. The reason it was the other way around is because the Carthfile werent matching the Podspec.

drdaz commented 5 years ago

The commit that seems to cause the current macOS build error here is the switch to Xcode 11 for the build. It's hard to be sure though, since there's such a long string of commits where nothing builds at all.

I can't reproduce the macOS issue locally; it does fail, but differently. I'm building using Xcode 10.3 (I haven't got 11 yet). There also seems to be a lot of non-macOS output when I'm trying to build it, with much of that coming from the Parse SDK dependency.

Darrens-MBP:ParseLiveQuery-iOS-OSX drdaz$ xcodebuild build -workspace ParseLiveQuery.xcworkspace -sdk macosx -scheme ParseLiveQuery-OSX -configuration Debug GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=YES GCC_GENERATE_TEST_COVERAGE_FILES=YES | xcpretty -c; Starscream will not be code signed because its settings don't specify a development team. (in target 'Starscream') ▸ Processing Info.plist ▸ Compiling Compression.swift ▸ Compiling WebSocket.swift ▸ Compiling SSLSecurity.swift ▸ Linking BoltsSwift ▸ Processing Info.plist ▸ Compiling BFCancellationToken.m ▸ Compiling BFTask.m ▸ Compiling BFTaskCompletionSource.m ▸ Compiling BFExecutor.m ▸ Compiling BFCancellationTokenRegistration.m ▸ Compiling BFCancellationTokenSource.m ▸ Compiling Bolts.m ▸ Analyzing BFCancellationTokenSource.m ▸ Analyzing BFTask.m ▸ Analyzing BFCancellationTokenRegistration.m ▸ Analyzing BFExecutor.m ▸ Processing Info.plist ▸ Analyzing Bolts.m ▸ Analyzing BFTaskCompletionSource.m ▸ Analyzing BFCancellationToken.m ▸ Generating 'BoltsSwift.framework.dSYM' ▸ Touching BoltsSwift.framework (in target: BoltsSwift-tvOS) ▸ Compiling Starscream_vers.c ▸ Linking Starscream ▸ Copying Starscream.h ▸ Touching Starscream.framework (in target: Starscream) ▸ Linking Bolts ▸ Generating 'Bolts.framework.dSYM' ▸ Copying BFTaskCompletionSource.h ▸ Copying Bolts.h ▸ Copying BFTask.h ▸ Copying BFGeneric.h ▸ Copying BFExecutor.h ▸ Copying BFCancellationTokenSource.h ▸ Copying BFCancellationToken.h ▸ Copying BFCancellationTokenRegistration.h ▸ Touching Bolts.framework (in target: Bolts-macOS) ▸ Processing Parse-iOS.Info.plist ▸ Running script 'Generate Localizable Strings' ▸ Compiling Parse.m ▸ Compiling PFAnonymousUtils.m ▸ Compiling PFProduct.m

⚠️ /Users/drdaz/Desktop/ParseLiveQuery-iOS-OSX/Carthage/Checkouts/Parse-SDK-iOS-OSX/Parse/Parse/PFProduct.h:16:1: This file is unavailable on OS X. [-W#pragma-messages]

PF_OSX_UNAVAILABLE_WARNING ^

▸ Compiling PFSQLiteDatabase.m ▸ Compiling PFPurchase.m

⚠️ /Users/drdaz/Desktop/ParseLiveQuery-iOS-OSX/Carthage/Checkouts/Parse-SDK-iOS-OSX/Parse/Parse/PFPurchase.h:15:1: This file is unavailable on OS X. [-W#pragma-messages]

PF_OSX_UNAVAILABLE_WARNING ^

⚠️ /Users/drdaz/Desktop/ParseLiveQuery-iOS-OSX/Carthage/Checkouts/Parse-SDK-iOS-OSX/Parse/Parse/Internal/Purchase/PaymentTransactionObserver/PFPaymentTransactionObserver.h:15:1: This file is unavailable on OS X. [-W#pragma-messages]

PF_OSX_UNAVAILABLE_WARNING ^

⚠️ /Users/drdaz/Desktop/ParseLiveQuery-iOS-OSX/Carthage/Checkouts/Parse-SDK-iOS-OSX/Parse/Parse/PFProduct.h:16:1: This file is unavailable on OS X. [-W#pragma-messages]

PF_OSX_UNAVAILABLE_WARNING ^

⚠️ /Users/drdaz/Desktop/ParseLiveQuery-iOS-OSX/Carthage/Checkouts/Parse-SDK-iOS-OSX/Parse/Parse/Internal/Purchase/Controller/PFPurchaseController.h:16:1: This file is unavailable on OS X. [-W#pragma-messages]

PF_OSX_UNAVAILABLE_WARNING ^

❌ /Users/drdaz/Desktop/ParseLiveQuery-iOS-OSX/Carthage/Checkouts/Parse-SDK-iOS-OSX/Parse/Parse/PFPurchase.m:37:30: property 'purchaseController' not found on object of type 'ParseManager *'

[[Parse _currentManager].purchaseController.transactionObserver handle:productIdentifier block:block];
 ^

❌ /Users/drdaz/Desktop/ParseLiveQuery-iOS-OSX/Carthage/Checkouts/Parse-SDK-iOS-OSX/Parse/Parse/PFPurchase.m:86:36: property 'purchaseController' not found on object of type 'ParseManager *'

return [Parse _currentManager].purchaseController;
                         ^

▸ Compiling PFDefaultACLController.m ▸ Compiling PFUser.m ▸ Compiling PFUserFileCodingLogic.m ▸ Compiling PFErrorUtilities.m ▸ Compiling PFURLSessionJSONDataTaskDelegate.m ▸ Compiling PFPushManager.m ▸ Compiling PFMutableQueryState.m ▸ Compiling PFURLSession.m ▸ Compiling PFPolygon.m ▸ Compiling PFOfflineStore.m ▸ Compiling ParseModule.m BUILD FAILED

▸ Compiling ParseManager.m

The following build commands failed: CompileC /Users/drdaz/Library/Developer/Xcode/DerivedData/ParseLiveQuery-hdbeayodejtexmelpvbrziazsbyd/Build/Intermediates.noindex/Parse.build/Debug/Parse-iOS.build/Objects-normal/x86_64/PFPurchase.o /Users/drdaz/Desktop/ParseLiveQuery-iOS-OSX/Carthage/Checkouts/Parse-SDK-iOS-OSX/Parse/Parse/PFPurchase.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler (1 failure) ▸ Compiling ParseClientConfiguration.m ▸ Compiling PFWeakValue.m ▸ Compiling PFUserState.m ▸ Compiling PFUserDefaultsPersistenceGroup.m ▸ Compiling PFUserController.m ▸ Compiling PFUserConstants.m ▸ Compiling PFUserAuthenticationController.m

drdaz commented 5 years ago

... looking at my error, there's more OS confusion.

From ParseManager.h:

if TARGET_OS_IOS || TARGET_OS_TV

@ property (nonatomic, strong) PFPurchaseController *purchaseController;

endif

So it looks like the whole Parse project is probably the iOS version.

EDIT: I'm talking nonsense. That the build fails accessing that property shows that we are building the macOS version. If it were the iOS version, the build wouldn't fail.

drdaz commented 5 years ago

@noobs2ninjas Do you know where in all this that the tests started building against 1.17.3?

drdaz commented 5 years ago

... I'm asking this because there's a chance that 1.17.3 is causing the problem here. I was messing around with the dependency setup in the project (including Bolts) while trying to learn how it works. Something could have landed wrong there.

noobs2ninjas commented 5 years ago

Ok so I've done a little digging.

So the way to get the mac build errors on circle is to run:

xcodebuild build -workspace ParseLiveQuery.xcworkspace -sdk macosx -scheme ParseLiveQuery-OSX -configuration Build GCC_GENERATE_TEST_COVERAGE_FILES=YES | xcpretty -c;

This gives us a few errors but both are different versions of the same thing 

/Carthage/Checkouts/Parse-SDK-iOS-OSX/Carthage/Checkouts/Bolts-ObjC/Bolts/iOS/BFWebViewAppLinkResolver.m:11:9: 'UIKit/UIKit.h' file not found

#import <UIKit/UIKit.h>
              ^______________________

I've checked several things. Which target of Bolts and Parse builds for ParseLiveQuery-OSX. Those looked fine. I checked if somehow the these files where selected as part of the Bolts-macOS target. That looks OK.

I did find two things that are kinda curious. First I found a file named iOS.modulemap in "Supporting Files" folder that mentions both of our offending files. 

framework module Bolts {
  umbrella header "Bolts.h"

  export *
  module * { export * }

  explicit module BFAppLinkResolving {
    header "BFAppLinkResolving.h"
    export *
  }
  explicit module BFWebViewAppLinkResolver {
    header "BFWebViewAppLinkResolver.h"
    export *
  }
}

Now I dont know how builds choose to include or not include these modulemap files but I'd imagine there is a chance that the new xcode version may have changed how modulemaps work. It would be a weird coinsidence that these are the two trouble classes both mentioned in the same file yet somehow this file isn't the problem.

The second thing is that for some strange reason there is two different Bolts projects if you fork or clone the master branch. One exists within the Parse project. The second is in the main ParseLiveQuery project. I dont know if these are merely references to the same Carthage project but somehow I doubt it. If that is the case then I suppose one may be setup incorrectly.

Anyway, I have a feeling that fixing these CircleCI build issues will probably fix the Travis build issues if they arent already identical.

noobs2ninjas commented 5 years ago

Once the main parse sdk is fixed on the built I'll get back to this.

noobs2ninjas commented 5 years ago

Hey @drdaz I think I have an idea of where this is coming from. I'm just not sure whos fault it is. As you can see in the image below we can see clearly that Bolts-iOS-Dynamic has the files causing the error building for both mac and iOS.

Bolts_xcodeproj

Now I'm not entirely sure how to fix this or what has it building those dynamic libraries since the target itself has the macOS specific framework building.

I know we get the build warning:

    Multiple targets match implicit dependency for product reference 'Parse.framework'. Consider adding an explicit dependency on the intended target to resolve this ambiguity. (in target 'ParseLiveQuery-OSX' from project 'ParseLiveQuery')
    Multiple targets match implicit dependency for product reference 'BoltsSwift.framework'. Consider adding an explicit dependency on the intended target to resolve this ambiguity. (in target 'ParseLiveQuery-OSX' from project 'ParseLiveQuery')

One thing I noticed is that unlike the other frameworks there is no xcconfig files for ParseLiveQuery. I also noticed that Parse have #include "Shared/Product/DynamicFramework.xcconfig" in their macOS.xcconfig.

I'm just so confused how this all gets setup. Is that rake file responsible for running the configs for Parse? If I just get on Parse-iOS-OSX and just change the project schemas will it fix it permanantly?

Its so hard since this happens when building ParseLiveQuery via console. Im not sure what to run to just build the Parse-iOS-OSX-SDK in console by itself so we can focus on that.

Any insight would be helpful. Unlike the Travis/CircleCI stuff this is completely foreign to me.

drdaz commented 5 years ago

Straight up, I'm not sure what we're looking at here.

I'd still recommend trying to build locally against SDK 1.17.2, to see if that changes the result. If it does we know which commits and changes to look at. Otherwise we're poking around in the dark. Or I am at least.

I'm not familiar enough with how this builds to know how to achieve that though. 😕

EDIT: I'm pushing that route because the CI history showed that this test did work. If the older version doesn't change the result, we'll have limited the search to this library.

drdaz commented 5 years ago

@noobs2ninjas I checked out your repo today, and I've been poking at this for some hours, and I'm not much wiser. But maybe a little.

I can say that the 'macOS + iOS' UI that you showed in the screengrab is related to Xcode 11 and more specifically Catalyst. In the main SDK, if I select the iOS target and disable 'Mac' as a device, then only iOS libs are shown (rather than 'macOS + iOS' as in your screenshot). This makes sense, since the new features in 10.15 let you build iOS-ish apps to the Mac. I wouldn't imagine this has anything to do with the issue we're seeing here in the macOS test though.

I have spent some time trying to build your repo against SDK 1.17.2 to see how that changes things. Unfortunately it breaks in a different way. That said, testing community/master with Xcode 11 seems to fail in a similar way; it tries to build the iOS version of Bolts in the macOS test (amongst a number of other errors). So it seems pretty safe to assume this isn't due to something you've changed, or something that changed in SDK 1.17.3 (master's Cartfile references SDK 1.16.0). This looks like an Xcode 11 thing.

Its so hard since this happens when building ParseLiveQuery via console. Im not sure what to run to just build the Parse-iOS-OSX-SDK in console by itself so we can focus on that.

For this you can check that repo out and build it using the commands specified in that repo? I suspect I'm misunderstanding your question.

Looking at the error output from this, though, this macOS target is selecting the iOS version of Bolts to compile from the main SDK:

❌ /Users/distiller/project/Carthage/Checkouts/Parse-SDK-iOS-OSX/Carthage/Checkouts/Bolts-ObjC/Bolts/iOS/BFWebViewAppLinkResolver.m:11:9: 'UIKit/UIKit.h' file not found

I've reproduced this locally. But I'm not sure why this is happening.

I do wonder though, why the LiveQuery workspace contains so many Bolts-related schemes. The main Parse SDK doesn't look like this. I mean, Bolts is in there, but not twice per target.

Screenshot 2019-11-28 at 17 00 34

So... maybe this poses more questions than it answers. But it's how I spent a big chunk of my day. I hope we can get this back on the rails soon; it's a problem for the product that people can't build it.

drdaz commented 5 years ago

Generally I find the way dependencies are handled in the main Parse SDK (and now, here) to be really confusing.

Maybe this is just how it is / was done, but it makes me feel funny... not in the good way.

drdaz commented 5 years ago

The good news; I just got the macOS test to pass on your repo.

Screenshot 2019-11-28 at 19 39 04

The bad news; I have no idea what exactly I've changed to make that happen.

I'll get back to you.

drdaz commented 5 years ago

Nailed it.

Can I get push access to your repo @noobs2ninjas?

drdaz commented 5 years ago

So it looks like I had push access. I pushed, and now CI can't check the code out 😩

drdaz commented 5 years ago

Æh.

Something to do with ruby on the CI environment it seems... I didn't change anything in the source to alter this afaik.

drdaz commented 5 years ago

CircleCI is ignoring the .ruby-version file on this PR for some reason. It's set to 2.6.3, but the server is trying to set it to something older and failing.

If anybody knows the right way to touch it up to make it happy, please do. Pretty sure the tests would work if they could run 😃

drdaz commented 5 years ago

Boom! 🙂

drdaz commented 5 years ago

I think we're good to go here now.

Once @TomWFox has given this another look, can we push a release? This has been incompatible with the main SDK for a really long time.

EDIT: It seems I bumped the minor version number for no reason at all. sigh

TomWFox commented 5 years ago

Also, As you’ve bumped the version number it would make sense to do the changelog in this pr too.

drdaz commented 5 years ago

Nice work, looks ok to me, love to see those green ticks 😍

Only query I have is why has the Facebook-objc-SDK been added to the Carthage config? - apologies if it’s already been mentioned but I haven’t been able to keep up with the whole thread!

It hasn't been added to the Carthage config; the Cartfile doesn't contain it. It presumably gets resolved as a dependency of the main SDK. This wasn't happening previously?

Also, As you’ve bumped the version number it would make sense to do the changelog in this pr too.

That would make sense I guess. I'll see if I can figure that out.

TomWFox commented 5 years ago

True, it shows up in the cartfile.resolved and the .gitmodules files. I don’t think it should be a dependency of the main SDK only the parseui and Facebook-Utils submodules?

drdaz commented 5 years ago

True, it shows up in the cartfile.resolved and the .gitmodules files. I don’t think it should be a dependency of the main SDK only the parseui and Facebook-Utils submodules?

Carthage doesn't support submodules, sadly. So the way the main SDK is structured, using Carthage, you get the whole shebang, dependencies and all.