-
Notifications
You must be signed in to change notification settings - Fork 986
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
feat(plugman): support framework link attribute #1266
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1266 +/- ##
==========================================
+ Coverage 78.25% 78.27% +0.02%
==========================================
Files 15 15
Lines 1761 1763 +2
==========================================
+ Hits 1378 1380 +2
Misses 383 383
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
EDIT: original comment:
|
1603313
to
54d4fe8
Compare
Nice, thank you. |
Your welcome. BTW, this PR is still in draft mode as cordova-common, cordova-lib, and cordova-cli PRs will likely become obselete as a result of apache/cordova-common#181. |
2bae77c
to
a2a1d84
Compare
Opening PR for review. Noting again, this PR requires a cordova-cli that is using [email protected]. If your environment does not contain this, cordova-ios will not receive the link attribute in an actual cordova project. |
a2a1d84
to
02255a2
Compare
Forced-push to update branch with master. |
6489c40
to
0f4b63e
Compare
The failing test does not appear to be related to this PR. We've investigated and determined that issue happens in current master on NodeJS 18. I've created a bug ticket with further details: #1290 |
Waiting on #1302 so that we can confirm if all test passes. |
9b0dc61
to
7e10b30
Compare
…pdate is backwards compatible with previous embed behaviour.
7e10b30
to
327010c
Compare
Update is backwards compatible with previous embed behaviour.
Platforms affected
iOS
Motivation and Context
Currently, the framework tag does not support both linking and embedding a framework. Comments in the code suggest this was a limitation in Apple's code.
This limitation no longer exists. The current default behaviour of XCode (version 14) when dragging and dropping an XCFramework into General -> "Frameworks, Libraries, and Embedded Content" is to both embed and link the XCFramework.
I have only tested this with XCFramework but I assume other kinds of frameworks are the same.
This change allows the framework tag to both link and embed a framework.
In my real-world use case, I am using custom XCFrameworks to get c binaries into my cordova app.
If the XCFramework is not embedded then the App will crash during runtime because it can not find the binaries. This is expected because the binaries were not embedded into the app.
If the XCFramework is not linked then the App can not be built due to linker errors. This is expected because the binaries are not being linked to the app.
cordova-ios unit tests use cordova-common directly. As a result, this PR depends on apache/cordova-common#181 (cordova-common 4.1.0).
In actual usage, cordova-cli parses the framework attributes and gives them to cordova-ios. As a result, this PR also depends on a cordova-cli that is using apache/cordova-common#181 (cordova-common 4.1.0)
cordova-docs pr: apache/cordova-docs#1267
Description
Add code that checks for new framework attribute "link".
If link is not explicitly set, fallback to the previous behaviour (link = !embed).
Testing
I've ran npm test.
Tested various combinations of framework tag's embed and link attributes by installing a plugin using these attributes. I would observe how the XCFramework is added to the the XCode project with the following focuses:
-Is the XCFramework embedded (or not embedded) in Build Phrases?
-Is the XCFramework linked (or not linked) in Build Phrases?
-Is the XCFramework set to "Embed and Sign" in General?
I have ran my company's app using these changes.
Checklist
(platform)
if this change only applies to one platform (e.g.(android)
)