-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
runtime cxx module autolinking #43054
Conversation
This pull request was exported from Phabricator. Differential Revision: D53602544 |
Summary: see https://fb.workplace.com/groups/2158787827656681/posts/2296646383870824/?comment_id=2303006146568181 for context >hi everyone, update on how this directional development is going. currently, RuntimeExecutor appears to fulfill ExpoModules needs and has been integrated successfully on iOS. however, there is still a question on how to migrate callsites that require the runtime "on demand" when they are already on the JS thread. example from reanimated here (https://github.com/.../react.../blob/main/apple/REAModule.mm). >Samuel and Pieter helped brainstorm a couple of options (exposing the raw runtime pointer, C++ turbomodules, deobfuscating the runtime pointer in the turbomodule invocation flow), but i felt like C++ turbomodule was the least hacky and had the most long-term prospects of these options. >since the blocker is autolinking, i prototyped a macro similar to RCT_EXPORT_MODULE for cxx modules only and i would like to get everyone's comments: D53602544. Nicola is investigating android atm. this implementation is inspired by RCT_EXPORT_MODULE, we keep a global data structure that maps module names to a lambda that returns the C++ turbomodule. this will come with a hit to startup time. the only way to avoid that is a codegen solution. this is a temporary solution because we don't have a proper autolinking solution for ios modules that doesn't require changes in user land. Differential Revision: D53602544
6a2716a
to
f80b712
Compare
This pull request was exported from Phabricator. Differential Revision: D53602544 |
Base commit: e4135e9 |
This pull request has been merged in 01d704d. |
Hey @philIip! I've tried your macro on iOS and confirmed that I added the compiler flags. I'm also using the same name in JS, but my module can't be registered. What works for me is the Obj-C macro with the load method: #define INIT_CXX_MODULE(NAME) \
@interface CxxModule: NSObject \
@end \
@implementation CxxModule \
+ (void)load { \
facebook::react::registerCxxModuleToGlobalModuleMap( \
std::string(facebook::react::NAME::kModuleName), \
[](std::shared_ptr<facebook::react::CallInvoker> jsInvoker){ \
return std::make_shared<facebook::react::NAME>(jsInvoker); \
} \
); \
} \
@end \ It seems like the C++ code is never executed and the module is not registered. Can you give me any hints on how to handle this? It would be perfect to initialize my C++ TurboModule from C++ without single Obj-C file. |
Summary:
Changelog: [iOS][Android][Added] Experimental macro to autolink C++ turbomodules
this implementation is inspired by RCT_EXPORT_MODULE, we keep a global data structure that maps module names to a lambda that returns the C++ turbomodule. this will come with a hit to startup time. the only way to avoid that is a codegen solution. this is an experimental solution because we don't have a proper autolinking solution for ios modules that doesn't require changes in the app layer.
How to use
In the .cpp file of your TurboModule, add the following line, where MyCxxNativeModule is the identifier of your module. This will automatically link the module on both iOS and Android. The class name of your TurboModule must match its JavaScript module identifier and live in the facebook::react namespace.
there's still a catch here, because the macro can still get compiled out if the compiler thinks the file is not being used. this is how you can work around this at the build level:
on android, in your CMakeLists.txt, pass in
-Wl, --whole_archive
toadd_compile_options
.on iOS, in the podspec, pass
"-Wl, --whole_archive"
as the value to"OTHER_LDFLAGS"
in thepod_target_xcconfig
.Differential Revision: D53602544