Open telip007 opened 8 years ago
It's quite a breaking change, most of the classes have been renamed, the SDK is built differently and there are tons of new features.
I've ported the extensions over to the new SDK in my fork (https://github.com/vzsg/FirebaseRxSwiftExtensions), but I'm a little hesitating to set up a PR, because there were some sacrifices.
That compilation error might be a bug in CocoaPods or a mistake on Google's part. Either way, if you add the new Firebase SDK to a brand new Pod library, the development pod cannot import the modules ("No such module" error), even though the example project can.
I think it might be because the SDK pods contain vendored frameworks instead of the old headers+dylib setup. But I'm just a newbie. If there's a clean solution, I'll clean up my fork in a jiffy.
I've been trying to do this project in https://github.com/RxSwiftCommunity/RxFirebase However I'm having quite some difficulty with exactly what @vzsg mentioned.
For those still on v2, please don't update just yet. You can migrate your database to the next console, but don't update your client specs.
As my projects heavily depend on RxSwift and Firebase. I'll be at Google IO in the morning down in the MountainView and will hopefully get some help.
@vzsg I added this issue to the Cocoapods repo seeking help as well: https://github.com/CocoaPods/CocoaPods/issues/5368
Trying to fix it right now but let me know ASAP if you have a solution!
Good luck!
I spent last night with experimenting instead of sleep, but I haven't found anything apart from the -undefined workaround I mentioned. :(
It's very hard to search for this issue, but this seems close enough, and doesn't help us at all: https://github.com/CocoaPods/CocoaPods/issues/3841
As I use FirebaseRxSwiftExtensions heavily, but will have to update to 3 soon, I think I'll just copy the source files into the app. That's another temporary workaround that doesn't involve killing Bitcode.
https://github.com/CocoaPods/CocoaPods/issues/3161
Is a good lead. But in the worst case scenario I will ask mike macdonald since he works on firebaseui which should effectively have the same pod layout (unfortunately I don't think it does) On Thu, May 19, 2016 at 1:10 AM Zsolt Váradi notifications@github.com wrote:
Good luck!
I spent last night with experimenting instead of sleep, but I haven't found anything apart from the -undefined workaround I mentioned. :(
It's very hard to search for this issue, but this seems close enough, and doesn't help us at all: CocoaPods/CocoaPods#3841
https://github.com/CocoaPods/CocoaPods/issues/3841
As I use FirebaseRxSwiftExtensions heavily, but will have to update to 3 soon, I think I'll just copy the source files into the app. That's another temporary workaround that doesn't involve killing Bitcode.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/RxSwiftCommunity/FirebaseRxSwiftExtensions/issues/8#issuecomment-220256140
Maximilian Alexander mbalex99@gmail.com http://blog.edenmsg.com
I've started a project, coincidentally, called RxFirebase. I've added extensions for Auth, Database and Storage. Going to do more but I need sleep... Have fun!
It seems this hack is getting popular, @neoplastic reached the same conclusion as I did last night:
s.pod_target_xcconfig = {
'ENABLE_BITCODE' => 'NO',
'FRAMEWORK_SEARCH_PATHS' => '$(inherited) $(PODS_ROOT)/**',
'OTHER_LDFLAGS' => '$(inherited) -undefined dynamic_lookup'
}
But xcodebuild complains about it (-unused is deprecated
and FirebaseDatabase is not a dylib
). We shouldn't do this in production...
Weird, I'm not getting those warnings.
Warnings or no, I don't think this is a solution. This definitely is a hack.
@neoplastic What did your podpsec look like. You said you implemented those methods so I assume your development pod classes built properly.
I copied the above lines from his podspec.
@mbalex99: Any news from the I/O?
I just talked to @mcdonamp about this and he agreed that the podspec was published oddly. I brought it up to their attention and sent him an email and he'll look into it.
@mbalex99 Yeah, what @vzsg copied is from my pod spec. The development pods build properly however indexing in Xcode is prone to mistakes and slowness which is not ideal but doesn't stop me from writing code backed on it, makes me hesitant to publish anything as a pod though.
Definitely there's a podspec weirdness on Firebase's side which without the hack makes it impossible to develop an extension library without it.
Also I believe some of the Google libraries are not bitcode compatible? Its quite likely, hopefully that can be resolved down the track too but I wouldn't hold my breath.
Firebase guys confirmed that their library is bitcode compatible. This is just a podspec issue at the moment!
Sorry, busy day, and now, long story...
"That compilation error might be a bug in CocoaPods or a mistake on Google's part. Either way, if you add the new Firebase SDK to a brand new Pod library, the development pod cannot import the modules ("No such module" error), even though the example project can."
This is super weird: the Firebase pod is built with Bitcode enabled, so it's pretty strange that you have to disable Bitcode in order to get your app to compile. We also build a sweet modulemap, so import Firebase
should just work.
OSX (along with tvOS and watchOS) support is something we're still working through: given that Firebase is now much more than just a database and an auth product, what it means to use features like Analytics, Config, Crash Reporting, and Invites/Dynamic links on these platforms, and how they interact with the various system resources is something we're still working through.
On the FirebaseUI podspec--I'll come clean and admit my hideous technical sins. It's a byproduct of a few things:
.xcodeproj
provided--we went ahead and built all the frameworks separately, globbed them together into a zip file, and shipped them to you in this fashion, solving the above problem while also keeping the onboarding experience cleaner (and providing the code as open source). Since our code labs and quickstarts depend on FirebaseUI, we had to ship this in a usable state and clean up later--this will likely end up being my weekend project.~/.cocoapods/repos/master/Specs/FirebaseUI/0.4.0
podspec to be my development pod (instead of using :path =>
), meaning I got around all the pathing issues, since it treated my pod like a real pod. If someone can get my any useful information on how development pods work, I'd love to hear that :)Short term, you can just copy the source of this library into your app and hack around it, though I don't anticipate that being a long term solution. Medium to long term, I see a few ways this could go:
FirebaseRXSwiftExtensions
pod as a vendored framework (as I'm doing for FirebaseUI)Very long term, if we stop supporting iOS 7 and build everything as a dynamic framework, everything will Just Work™
Happy to work with folks on these, since I definitely have a vested interest (through FirebaseUI, as well as just as a developer who builds on Firebase) to have a cleaner solution to this problem.
Thanks @mcdonamp that clears a whole lot up! I'm looking forward to implementing the shiny new stuff!
@neoplastic are you familiar with how to do weak frameworks?
I'm assuming that @mcdonamp is referring to the podspec weak_frameworks thus requiring that the base project includes the required libraries in the podfile.
I've not used this myself though, never really needed to until now.
Alright so I'm guessing
Correct me if I'm wrong?
On Sat, May 21, 2016 at 7:06 PM neoplastic notifications@github.com wrote:
I'm assuming that @mcdonamp https://github.com/mcdonamp is referring to the podspec weak_frameworks https://guides.cocoapods.org/syntax/podspec.html#tab_weak_frameworks thus requiring that the base project includes the required libraries in the podfile.
I've not used this myself though, never really needed to until now.
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/RxSwiftCommunity/FirebaseRxSwiftExtensions/issues/8#issuecomment-220810290
Maximilian Alexander mbalex99@gmail.com http://blog.edenmsg.com
@mcdonamp
Hey Mike, I talked to a ton of people and it looks like most Google published pods have a lot incompatibilities. I searched and I think SegmentIO's pods which uses GoogleAnalytics seem to not have this issue.
I can't tell what they're doing that's so special but the pod with development classes works fine here: https://github.com/segment-integrations/analytics-ios-integration-google-analytics/blob/master/Segment-GoogleAnalytics.podspec
Has anyone found a solution for this?
@mcdonamp Do you think you can create a dynamically linked framework and static version at the same time like how Localytics does it?
This is what they have in their docs
In your Podfile add the following content
platform :ios, '8.0'
pod 'Localytics', '~> 4.0'
The Localytics pod uses a dynamic framework. If you need to use a static binary (e.g. you support iOS 7) then use the following pod
platform :ios, '7.0'
pod 'LocalyticsStaticFramework', '~> 4.0'
It's something I've thought of, though I'm not sure how feasible it is with our current build process. I'll ask around and see if we can come up with a better solution.
@mcdonamp Let me know how if I can help in anyway. I just updated the RxJavaFirebase and RxJSFirebase projects with extreme ease but this one is a toughie especially with Swift PKG manager coming out in full force lately.
@mbalex99 looks like we're planning a transition to dynamic frameworks for the CocoaPod, though no word on timeline. I'll let you know if you can help out though, especially when it comes to testing this :)
@mcdonamp I will take you out for drinks if you can push it! Thank you so much!
Have to update the requirements...