Skip to content
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

Merged
merged 22 commits into from Jun 16, 2020

Conversation

paulb777
Copy link
Member

@paulb777 paulb777 commented Jun 15, 2020

  • Update client imports to GoogleUtilities to use repo-relative imports - following up GoogleUtilities repo-relative imports #5810
    • The clients were updated with the next incarnation of scripts/change_headers.swift
  • Initial Swift Package Manager CI for GoogleUtilities and FirebaseCore - (productizing prototype code in the spm-master2020 branch.
  • Bump GoogleUtilities minor version and its clients podspec dependency
  • Updated GoogleUtilities header structure to minimize deltas between CocoaPods and SPM
    • Where possible, treated the CocoaPods Private folder as public.
    • When not possible because of intra-pod imports in the Private headers, created a Public/dummy.h to treat the Privates as Private.
    • The GoogleUtilities header organization should be revisited and made more consistent when breaking changes are allowed with Firebase 7. There is not a consistent definition between public and private header usage currently.

@google-oss-bot
Copy link

1 Warning
⚠️ Did you forget to add a changelog entry? (Add #no-changelog to the PR description to silence this warning.)

Generated by 🚫 Danger

@paulb777 paulb777 marked this pull request as ready for review June 15, 2020 23:32
@@ -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 {
Copy link
Contributor

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?

Copy link
Member Author

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"
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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

Base automatically changed from pb-gu-rr to master June 16, 2020 13:19
@paulb777
Copy link
Member Author

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>
Copy link
Contributor

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:

https://github.com/invertase/react-native-firebase/blob/67c52a8aaeac32d2253e73769313e49700bc497c/packages/messaging/ios/RNFBMessaging/RNFBMessaging%2BAppDelegate.m#L20

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

Copy link

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.

Copy link
Contributor

@mikehardy mikehardy Jul 15, 2020

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]

Copy link
Member

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.

mikehardy added a commit to invertase/react-native-firebase that referenced this pull request Jul 15, 2020
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
@firebase firebase locked and limited conversation to collaborators Jul 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants