You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Library authors might want to publish packages containing prebuilds for Node.js alongside the React Native specific prebuilds, if they have a use-case for targeting Node.js or wants to make it easier for app developers to test without having to mock the native addon of the library.
Library authors can use cmake-js, node-gyp (if they use CMake or GYP respectively) to build for Node.js.
By default, both cmake-js and node-gyp output the dynamic library produced when building to ${projectRoot}/build/${configuration}/${targetName}.node.
☝ has the disadvantage that dynamic libraries compiled on different operating systems / architectures share the same path of disk.
Developers use tools like prebuild or prebuildify (supports only GYP), to build and structure multiple os+arch specific binaries.
The cmake-rn store its output platform-specific & arch-specific subdirectories of ${projectRoot} (see out PREBUILDS.md for details on the structure of these directories).
Note
${projectRoot} in the paths above is not the package root, but instead the directory containing the binding.gyp or CMakeLists.txt configurations of the particular build system.
It's annoying to have to invoke multiple tools (which might have slightly different runtime options / args).
Ideally a library author should be able to just select the platforms / triplets they want to build for:
React Native (iOS / Android)
Node.js (Windows, Linux, MacOS)
To be more compatible with the existing tools for Node.js, we could:
write our prebuilds into the ${projectRoot}/build/${configuration} directory, the same way cmake-js and node-gyp does.
make it easier to build for Node.js
by adding Node.js as a target for cmake-rn (feels wrong, as the -rn suffix).
provide yet another CLI wrapping cmake-js and cmake-rn (feels a bit too abstracted).
provide yet another CLI with direct support for multiple platforms / operating-systems, with a pluggable architecture to make it easier to add support for future out-of-tree platforms as well.
Library authors might want to publish packages containing prebuilds for Node.js alongside the React Native specific prebuilds, if they have a use-case for targeting Node.js or wants to make it easier for app developers to test without having to mock the native addon of the library.
Library authors can use
cmake-js,node-gyp(if they use CMake or GYP respectively) to build for Node.js.Annoyance #1: Prebuild / output location
By default, both
cmake-jsandnode-gypoutput the dynamic library produced when building to${projectRoot}/build/${configuration}/${targetName}.node.☝ has the disadvantage that dynamic libraries compiled on different operating systems / architectures share the same path of disk.
Developers use tools like
prebuildorprebuildify(supports only GYP), to build and structure multiple os+arch specific binaries.The
cmake-rnstore its output platform-specific & arch-specific subdirectories of${projectRoot}(see out PREBUILDS.md for details on the structure of these directories).Note
${projectRoot}in the paths above is not the package root, but instead the directory containing thebinding.gyporCMakeLists.txtconfigurations of the particular build system.Annoyance #2: Executing two commands
It's annoying to have to invoke multiple tools (which might have slightly different runtime options / args).
Ideally a library author should be able to just select the platforms / triplets they want to build for:
To be more compatible with the existing tools for Node.js, we could:
${projectRoot}/build/${configuration}directory, the same waycmake-jsandnode-gypdoes.cmake-rn(feels wrong, as the-rnsuffix).cmake-jsandcmake-rn(feels a bit too abstracted).