fix: Prioritise local cpp (use default as fallback)

[timbocole]

Summary:

#47379 removed local cpp sources from the sources being built with the app. This resulted in a local android/app/src/main/jni/OnLoad.cpp file being ignored at build time. I have therefore added logic to the cmake file to prioritise local cpp files and fallback to ${REACT_ANDROID_DIR}/cmake-utils/default-app-setup/*.cpp if none exist.

This resolves #48298

Changelog:

[ANDROID] [FIXED] - Prioritise local OnLoad.cpp, falling back to default-app-setup

Test Plan:

• Followed the https://reactnative.dev/docs/the-new-architecture/pure-cxx-modules guide (which was broken > 0.76.1)
• Applied the patch to the reproduction repository linked to [0.76] Project with custom C++ code - Crashes with EarlyJsError: TurboModuleRegistry.getEnforcing(...): 'PlatformConstants' could not be found. Verify that a module by this name is registered in the native binary #47352 to ensure no regression

[facebook-github-bot]

Hi @timbocole!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[cipolleschi]

Thanks for taking a stab at this.
However, I'm not sure that this is the right solution.

I'll try to explain:

• We have one case where we want to load the OnLoad.cpp provided by the app, for example when we have local Cxx modules, as described by the issue #48298
• We also have one case where we always want to load the OnLoad.cpp file provided by React Native, for example for issue #47352 that was fixed by @cortinico's commit 3956955

The proposed solution will fix the first case, but it will break the second again.

I think that the right solution should be to enhance the autolinking codegen not only to consider the dependencies in the node_modules but also to consider the modules provided by the app in the codegenConfig property of the package.json.

In that way, the default OnLoad.cpp will load autolinking that, at this point, will also have the information of the local modules provided by the app.

However, this is an architectural and delicate change that should be evaluated also by @cortinico once he is back from PTO.

[timbocole]

Thanks for taking a stab at this. However, I'm not sure that this is the right solution.

I'll try to explain:

• We have one case where we want to load the OnLoad.cpp provided by the app, for example when we have local Cxx modules, as described by the issue #48298
• We also have one case where we always want to load the OnLoad.cpp file provided by React Native, for example for issue #47352 that was fixed by @cortinico's commit 3956955

The proposed solution will fix the first case, but it will break the second again.

I think that the right solution should be to enhance the autolinking codegen not only to consider the dependencies in the node_modules but also to consider the modules provided by the app in the codegenConfig property of the package.json.

In that way, the default OnLoad.cpp will load autolinking that, at this point, will also have the information of the local modules provided by the app.

However, this is an architectural and delicate change that should be evaluated also by @cortinico once he is back from PTO.

Actually this solution does consider issue #47352 (thanks to the else() which is entered when the override_cpp_SRC returns empty) - I have checked this by running the reproduction with my fix.

Having said that, I agree that the cleaner longterm approach would be to make the autolinking codegen more intelligent.
Will have to just utilise my patch to use local TMs until a better solution is implemented as without, local Android TMs (including the sample listed in the docs) are completely broken.

[cipolleschi]

Thanks for checking the other issue as well. The code is good to me, and I agree that the current situation is bad.
However, I don't think we are going to make a release of 0.76 over Christmas time, so we can wait for Nicola to be back and validate the solution as a patch to restore all the features.

Meanwhile, I can add a warning on the website for people that are trying to create a pure C++ TurboModule in their app.

Website PR: facebook/react-native-website#4402