Repository navigation
refactor: organize native sources and header exports - #39
Conversation
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: caeb4de569
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "GCC_PREPROCESSOR_DEFINITIONS": ["$(inherited)", "OPENRENDERBOX_CF_CGTYPES"], | ||
| "SWIFT_ACTIVE_COMPILATION_CONDITIONS": ["$(inherited)", "OPENRENDERBOX_CF_CGTYPES"], |
There was a problem hiding this comment.
For standalone framework consumers, these project-level definitions are not propagated when importing the copied bundle. The exported ORBPath.h, ORBPathCallbacks.h, and ORBPathStorage.h all guard their declarations with #if OPENRENDERBOX_CF_CGTYPES, but neither the exported headers nor the generated framework module map defines that macro. Consequently, the framework builds its native path implementation while ordinary C and Swift consumers cannot see its path API unless they manually supply an undocumented build flag. Encode the framework's fixed backend configuration in its exported headers so clients see the same API that was built; the current framework client test only exercises color and animation APIs and misses this mismatch.
Useful? React with 👍 / 👎.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #39 +/- ##
=======================================
Coverage 25.38% 25.38%
=======================================
Files 14 14
Lines 524 524
=======================================
Hits 133 133
Misses 391 391 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Native C++ and Objective-C headers were separated from their implementations, and new exported headers required several manual updates. Group native code by feature while keeping the public
<OpenRenderBox/...>include paths.OpenRenderBoxCxxas a static library linked into the dynamicOpenRenderBox.framework. Derive the framework module map from the SwiftPM map and copy real header contents into the bundle. Export the fixed CoreGraphics backend configuration so clients can use path APIs without extra compiler flags.Scripts/add_header.py <header> <module>to create public links and register headers. Repeated calls are safe, and conflicts leave existing files intact.Headersand exclude them from Tuist resource bundles. Update the header template script and document header registration.Validation:
Header helper: 10 tests passed on Linux and macOS, including repeat calls, missing links, conflicts, and C++ template headers.
SwiftPM build and test passed on both platforms. Linux: 21 tests, with 2 existing known issues. macOS: 28 passed and 37 skipped.
macOS Release framework build passed. Standalone C, C++, Objective-C, and Swift consumers passed using a copied bundle and its Swift interface.
Newly registered headers and template headers were also built and checked in a separate framework fixture.
Path APIs passed standalone header checks and consumer tests without a backend compiler flag. A conflicting framework backend flag is rejected.
macOS SwiftPM also builds with
OPENRENDERBOX_CF_CGTYPES=0.