Repository navigation
Error about transitive dependencies that include static binaries #23
Description
I'm getting the following when I install the FirebaseUI pod (0.3.0):
± |master ✗| → pod install
Updating local specs repositories
Analyzing dependencies
Downloading dependencies
Installing Bolts (1.5.0)
Installing FBSDKCoreKit (4.8.0)
Installing FBSDKLoginKit (4.8.0)
Using Firebase (2.4.3)
Installing FirebaseUI (0.3.0)
Installing Google (1.2.1)
Installing GoogleAppUtilities (1.0.0)
Installing GoogleAuthUtilities (1.0.1)
Installing GoogleInterchangeUtilities (1.1.0)
Installing GoogleNetworkingUtilities (1.0.0)
Installing GoogleSignIn (2.4.0)
Installing GoogleSymbolUtilities (1.0.3)
Installing GoogleUtilities (1.1.0)
[!] The 'Pods-my-project' target has transitive dependencies that include static binaries: (/.../my-project/Pods/Google/Libraries/libGGLCore.a and /.../my-project/Pods/Google/Libraries/libGGLSignIn.a)
Running CocoaPods 0.39.0. I'd love to be able to pull in a version of FirebaseUI that doesn't have all of the additional dependencies for various login providers.
Activity
ianzitow commentedon Nov 30, 2015
Me too!
stefanp312 commentedon Nov 30, 2015
Same with me. I fixed it by doing this with my pod file.
pod 'Firebase'
pod 'FirebaseUI', '= 0.2.6'
henriquesobral commentedon Nov 30, 2015
+1
asciimike commentedon Nov 30, 2015
Let's separate this into two issues:
use_frameworks!it will work, since all the deps will be static, though this prevents the use of dynamic frameworks.FirebaseUI/CoreandFirebaseUI/AuthorFirebaseUI/CoreandFirebaseUI/Providers. Anyone have any preference?@davideast thoughts?
Fixes pertaining to #22 and #23:
asciimike commentedon Dec 1, 2015
Item 2 will be fixed in #24, as it will allow for /Auth and /Core. /Provider is in the works, but will take a little while.
We're taking a look at the cases where Google fails out due to transitive deps on static libs--I think it's what I mentioned above, so I would try to use them statically if possible.
chrisellsworth commentedon Dec 1, 2015
Thanks Mike!
Indeed removing
use_frameworks!does the trick. I'll stick with that until another pod necessitates otherwise.As far as
/Authvs/Providergoes, I'd be a fan of separate/Providers for each provider since the Google support libraries appear to be fairly hefty and it leaves some room for expansion without further bloat should other providers be supported in the future. But I don't plan to use auth at all initially, so I defer to someone whom it may matter more to :)asciimike commentedon Dec 1, 2015
Yeah, we're thinking the same thing--though we'll start with
/Authand then move to/Providers in a later release (keeping/Authas the sum of all providers).Any reason you're not planning on using auth? Just don't need it while prototyping the app, too difficult to set up providers or security rules, something else?
chrisellsworth commentedon Dec 1, 2015
Something else :) I'll explain over email as not to derail this thread
asciimike commentedon Dec 1, 2015
Ok, I'm going to mark this as "Works as Intended" after 0.3.1 (just shipped) since the fix here is to remove
use_frameworks!or switch to usingFirebaseUI/Coreif you don't need auth.If you need to use
use_frameworksfor Swift only libraries in addition toFirebaseUI/Authin the future, please create a new bug that references the issue, and we'll see about how to fix it. #26 has been created to track multiple providers (which will partially solve the issue for users of auth providers other than Google).