SPM for Functions #5754
SPM for Functions #5754
Conversation
Generated by 🚫 Danger |
| #if SWIFT_PACKAGE | ||
| @import FirebaseCore; | ||
| @import GTMSessionFetcherCore; | ||
| #import "FirebaseCore/Sources/Private/FIRAppInternal.h" |
There was a problem hiding this comment.
Why not adopt repo-relative imports for all private headers?
And for that matter, if that works, why not just use repo-relative imports for all the headers?
As it stands this is an unmaintainable mess. People will develop one way and fail to update the imports on the other side. This doesn't seem long term viable without finding a way to just have one set of imports.
There was a problem hiding this comment.
We should migrate to all repo-relative internal headers, but I'd prefer to work on standardization on master and separate from the Swift Package Manager branch.
Public headers cannot be repo relative because they'll generate conflicts with module-imports. The exception is public header imports from a non-header source in the same target.
There was a problem hiding this comment.
But surely there has to be a way to hide this so that not every client of FirebaseCore has to have this mess inside it.
Consider an alternative:
FirebaseCore has a private header that contains:
#if SWIFT_PACKAGE
@import FirebaseCore;
#else
#import <FirebaseCore/FirebaseCore.h>
#endifNow functions is none the wiser about this; we just adopt the convention that imports from one SDK to another always use our private umbrella header.
As it stands, this is creating a mass of technical debt. Honestly, I can't even read what's going on here and have a hard time understanding whether or not imports are being handled equivalently on both sides of the #else. Now that storage is done I think we're past the point of prototyping and we need to address this issue.
There was a problem hiding this comment.
OK, addressing in #5758 and will rebase or reimplement this PR after that.
|
Replaced by #5858 |
4 participants
And remove Core, IID, and FIS from selectable products.