-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update GoogleUtilities' clients with repo-relative imports #5824
Conversation
Generated by 🚫 Danger |
@@ -107,16 +113,22 @@ let headerMap = getHeaderMap(url) | |||
for root in changeImports { | |||
let rootURL = url.appendingPathComponent(root) | |||
let enumerator = FileManager.default.enumerator(atPath: rootURL.path) | |||
while let file = enumerator?.nextObject() as? String { | |||
whileLoop: while let file = enumerator?.nextObject() as? String { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder what whileLoop:
does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The label enables the continue from a doubly nested loop. See line 128.
@@ -14,7 +14,7 @@ | |||
* limitations under the License. | |||
*/ | |||
|
|||
#import "GoogleUtilities/Environment/Public/GULKeychainStorage.h" | |||
#import "GoogleUtilities/Environment/Private/GULKeychainStorage.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if there is a way to implement test apps like #5828 with this structure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that test apps should depend on the repo structure. My intent is to only change the library sources and unit test imports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue (existing one already) that there are no actual public header in GoogleUtilities/Environment (they are marked as private now). I was going to make them public. Do you think it may be an issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. We should avoid public headers since they require ifdef'ing between Swift Package Manager and CocoaPods. See the Logger and NSData changes in this PR for details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels a bit weird to have a library without public API, but it's probably out of scope of the PR, we may discuss it later
258de96
to
714e391
Compare
cc: @eldhosembabu @chliangGoogle @karenyz @christibbs |
@@ -22,10 +22,10 @@ | |||
#import <FirebaseInstanceID/FirebaseInstanceID.h> | |||
#import <FirebaseMessaging/FIRMessaging.h> | |||
#import <FirebaseMessaging/FIRMessagingExtensionHelper.h> | |||
#import <GoogleUtilities/GULAppDelegateSwizzler.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @paulb777 :-), turns out react-native-firebase was using the GULAppDelegateSwizzler:
And with 6.7.0 of GoogleUtilities / 6.28.0 of firebase-ios-sdk we get a build error invertase/react-native-firebase#3938 as GULAppDelegateSwizzler.h tries to pull in GULApplication.h but it's not found:
ios/Pods/Headers/Private/GoogleUtilities/GULAppDelegateSwizzler.h:19:9: 'GoogleUtilities/AppDelegateSwizzler/Private/GULApplication.h' file not found
I'm ace at the Java side of the react-native house but my Objective-C skills sadly leave something to be desired.
I attempted to alter the import in our repo to match the change here ( #import "GoogleUtilities/AppDelegateSwizzler/Private/GULAppDelegateSwizzler.h"
) without success
Is there a simple trick I'm missing that will resolve the headers and allow our auto-swizzling for react-native library consumers to work, or is this a more serious structural issue?
Sorry to bother, but thanks in advance for any help
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out that the Firebase SDK for Unity was also using GULAppDelegateSwizzler. :/. We temporarily fixed the issue by adding this entry to the Podfile on our project:
pod 'GoogleUtilities', '6.6.0'
Hope this is fixed soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least our repo isn't alone @alejobrainz :-), we have a user report confirming that pinning the GoogleUtilities dep at 6.6.0 works for us as well, at least for firebase-ios-sdk pods 6.27.1, still building against 6.28.0 but with GoogleUtilities pinned on 6.6.0 to see [update: 6.28.0 may not be used by react-native-firebase until we figure out how to resolve it, 6.27.1 is the latest that appears to work]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the issue - I see it's been reported at #6047 so we'll make all progress updates there and continue the discussion for greater visibility.
This allows the messaging module to compile against firebase-ios-sdk <= 6.27.1 successfully It is not compatible with firebase-ios-sdk >= 6.28.0 A real fix is pending resolution of #3938 / Adaptation to firebase/firebase-ios-sdk#5824
scripts/change_headers.swift
Private
folder as public.