Grouping four TODOs that all come down to the same thing: the set of targets we build for is hardcoded or guessed, rather than derived from the toolchain and the project being built.
cmake-rn: default triplets are a heuristic
In current-development mode both platforms guess which device the developer is targeting instead of asking:
|
} else if (mode === "current-development") { |
|
// We're applying a heuristic to determine the current simulators |
|
// TODO: Run a command to probe the currently running simulators instead |
|
return ["arm64;x86_64-apple-ios-sim"]; |
https://github.com/callstackincubator/react-native-node-api/blob/29a527d87fa8cb965b0048b1b4c1cff2b0eab281/packages/cmake-rn/src/platforms/android.ts#L106-L109
Apple always returns arm64;x86_64-apple-ios-sim, so a developer iterating against a physical device or a tvOS/visionOS simulator silently builds the wrong slice. Android infers the ABI from process.arch, i.e. from the host architecture, which is wrong whenever the running emulator's ABI differs from the machine's. Both could be replaced with a probe — xcrun simctl list devices booted --json and adb devices + adb shell getprop ro.product.cpu.abi respectively — falling back to today's heuristic when nothing is booted.
cmake-rn: no default triplets at all outside the env var
|
// TODO: Derive default build triplets |
|
// This is especially important when driving the build from within a React Native app package. |
As the TODO notes, this matters most when the build is driven from within a React Native app package, where the app's own configuration already says which platforms and architectures are in play.
ferric: hardcoded Apple target list
|
// TODO: Consider calling out to rustup to generate this list or just use @napi-rs/triples |
|
export const APPLE_TARGETS = [ |
The list has to be kept in sync with Rust's supported targets by hand, and the commented-out Catalyst entries show it already drifting. Either query rustup target list or take the list from @napi-rs/triples.
These can land separately; they are filed together because a fix for one informs the shape of the others.
Grouping four
TODOs that all come down to the same thing: the set of targets we build for is hardcoded or guessed, rather than derived from the toolchain and the project being built.cmake-rn: default triplets are a heuristicIn
current-developmentmode both platforms guess which device the developer is targeting instead of asking:react-native-node-api/packages/cmake-rn/src/platforms/apple.ts
Lines 251 to 254 in 29a527d
https://github.com/callstackincubator/react-native-node-api/blob/29a527d87fa8cb965b0048b1b4c1cff2b0eab281/packages/cmake-rn/src/platforms/android.ts#L106-L109Apple always returns
arm64;x86_64-apple-ios-sim, so a developer iterating against a physical device or a tvOS/visionOS simulator silently builds the wrong slice. Android infers the ABI fromprocess.arch, i.e. from the host architecture, which is wrong whenever the running emulator's ABI differs from the machine's. Both could be replaced with a probe —xcrun simctl list devices booted --jsonandadb devices+adb shell getprop ro.product.cpu.abirespectively — falling back to today's heuristic when nothing is booted.cmake-rn: no default triplets at all outside the env varreact-native-node-api/packages/cmake-rn/src/cli.ts
Lines 42 to 43 in 29a527d
As the
TODOnotes, this matters most when the build is driven from within a React Native app package, where the app's own configuration already says which platforms and architectures are in play.ferric: hardcoded Apple target listreact-native-node-api/packages/ferric/src/targets.ts
Lines 18 to 19 in 29a527d
The list has to be kept in sync with Rust's supported targets by hand, and the commented-out Catalyst entries show it already drifting. Either query
rustup target listor take the list from@napi-rs/triples.These can land separately; they are filed together because a fix for one informs the shape of the others.