Two TODOs in cmake-rn, one per platform, where a build setting is pinned to the value that suits our own test app and cannot be overridden by a consumer.
Two separate PRs.
Apple: code signing is always disabled
|
|
|
// Skip code-signing (needed when building free dynamic libraries) |
|
// TODO: Make this configurable |
|
"CODE_SIGNING_ALLOWED=NO", |
|
]); |
CODE_SIGNING_ALLOWED=NO is the right default for the free-standing dynamic libraries we produce, but it is passed unconditionally. A consumer who needs signed binaries in the XCFramework — enterprise distribution, or a target whose downstream tooling verifies signatures — has no way to ask for it.
Android: the STL is always c++_shared
https://github.com/callstackincubator/react-native-node-api/blob/29a527d87fa8cb965b0048b1b4c1cff2b0eab281/packages/cmake-rn/src/platforms/android.ts#L152-L154
c++_shared is the correct choice for an app that loads several native libraries, and matches what React Native itself uses, so it should stay the default. But an addon that is genuinely self-contained may want c++_static, and — more importantly — an addon that must match a prebuilt third-party dependency has no say today. Getting this wrong is not a build error; it surfaces as duplicate STL symbols or subtle allocator mismatches at runtime, which makes the lack of an escape hatch worse than usual.
Both are single values that want the same treatment: keep the current value as the default, and let it be overridden. Note that #227 (pass-through of arbitrary runtime arguments to CMake) may cover the Android case for free — worth settling that first, since a generic pass-through would subsume ANDROID_STL but not the Xcode-level CODE_SIGNING_ALLOWED, which is appended after -- to xcodebuild rather than passed at configure time.
Two
TODOs incmake-rn, one per platform, where a build setting is pinned to the value that suits our own test app and cannot be overridden by a consumer.Two separate PRs.
Apple: code signing is always disabled
react-native-node-api/packages/cmake-rn/src/platforms/apple.ts
Lines 442 to 446 in 29a527d
CODE_SIGNING_ALLOWED=NOis the right default for the free-standing dynamic libraries we produce, but it is passed unconditionally. A consumer who needs signed binaries in the XCFramework — enterprise distribution, or a target whose downstream tooling verifies signatures — has no way to ask for it.Android: the STL is always
c++_sharedhttps://github.com/callstackincubator/react-native-node-api/blob/29a527d87fa8cb965b0048b1b4c1cff2b0eab281/packages/cmake-rn/src/platforms/android.ts#L152-L154c++_sharedis the correct choice for an app that loads several native libraries, and matches what React Native itself uses, so it should stay the default. But an addon that is genuinely self-contained may wantc++_static, and — more importantly — an addon that must match a prebuilt third-party dependency has no say today. Getting this wrong is not a build error; it surfaces as duplicate STL symbols or subtle allocator mismatches at runtime, which makes the lack of an escape hatch worse than usual.Both are single values that want the same treatment: keep the current value as the default, and let it be overridden. Note that #227 (pass-through of arbitrary runtime arguments to CMake) may cover the Android case for free — worth settling that first, since a generic pass-through would subsume
ANDROID_STLbut not the Xcode-levelCODE_SIGNING_ALLOWED, which is appended after--toxcodebuildrather than passed at configure time.