-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Remove CocoaPods #23951
Remove CocoaPods #23951
Conversation
That's for the value `CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER`, but it's useless to set `$(inherited)` for a Yes or No value because removing the value from the target will automatically make Xcode read it from the project, achieving the same result.
Was giving errors in Yoga: > Double-quoted include "YGEnums.h" in framework header, expected angle-bracketed instead
It resulted in a build failure: > React.framework/Headers/RCTAppearance.h:16:60: > A function declaration without a prototype is deprecated in all versions of C
Generated by 🚫 Danger |
Strange that `pod deintegrate` did not remove it. Maybe it was some custom piece of setup...
As we start removing CocoaPods from some of our projects, we can no longer assume pods exist locally to install. See wordpress-mobile/WordPress-iOS#23951 which prompted this change.
We don't have pods anymore
📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
|
/// WordPressKit, now imported via CocoaPods, has the `AppExtension Safe API Only` flag set to *true*. Meaning that | ||
/// the host app is, effectively as of now, responsible for presenting any alert onscreen (whenever a HTTP Challenge is | ||
/// received). Capicci? | ||
/// |
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.
This was a very old comment. It didn't seem to explain much to me, so I got rid of it.
#import "WordPressAuthenticator-Swift.h" | ||
#else | ||
#import <WordPressAuthenticator/WordPressAuthenticator-Swift.h> | ||
#endif |
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.
This was only useful for the CocoaPods setup. I noticed it grepping for CocoaPods and removed it. There were only two usages anyway, which I updated to the generated header, see below.
📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
|
As we start removing CocoaPods from some of our projects, we can no longer assume pods exist locally to install. See wordpress-mobile/WordPress-iOS#23951 which prompted this change.
Love the I'll try moving the changes there today. |
@kean seems like everything worked fine. See #23958 — There are CI failures, but look unrelated to the changes, as they match what's in the base branch, example https://buildkite.com/automattic/wordpress-ios/builds/25312 |
|
Closing in favor of #23958 |
Picks up where #23750, but starting from scratch because of too many project file changes since then, and completes the migration away from CocoaPods as the mean of linking the Gutenberg XCFramework.
The sequence of changes is roughly:
xcframework
sApp.js
file from the XCFramework to the build products as ajsbundle
to use the new locationTwo things noteworthy:
CLANG_WARN_STRICT_PROTOTYPES
andCLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER
, because of build failures in the XCFramework imports. It doesn't seem ideal, but also we have increasingly less Objective-C so it should be acceptable. Open to suggestions.make dependencies
before building the app. It felt a build phase was a bit too much, but it also feels like a line in theREADME
to call attention to this is not enough. Open to suggestions.Testing
I published this from the Simulator: https://giotestdotsite.wordpress.com/2025/01/07/via-gutenbegkit-without-cocoapods/ — Not sure if the HTML source can show it, but I did check locally that the experimental editor toggle was disabled. Besides, the UI being a bit different between the two helps being aware of it.
Apart from that, I'd say run the prototype build on device and see if the Gutenber-via-XCFramework editor works as expected.
Regression Notes
It's possible that some behavior in the Gutenber-XCFramework editor will be compromised. However, I don't see why, once the editor loads, all the code should be the same.
Had a go at publishing a post from the Simulator.
N.A.
PR submission checklist:
RELEASE-NOTES.txt
if necessary. - N.A.Testing checklist: