[Android/Windows] ninja mkdir fails for arm64-v8a build: absolute path with drive letter creates unresolvable C_/ directory

[atuldedha]

Environment

• OS: Windows 11
• @rive-app/react-native version: 0.4.6
• React Native version: 0.83.6
• Expo SDK: 53
• Build tool: expo run:android / gradlew assembleDebug
• CMake: 3.22.1 (Android SDK bundled)
• Ninja: bundled with Android SDK CMake

What went wrong

Building @rive-app/react-native for arm64-v8a on Windows fails with:

ninja: error: mkdir(CMakeFiles/rive.dir/C_/Users//...//node_modules/@rive-app/react-native/nitrogen/generated): No such file or directory

Steps to reproduce

1. Create a React Native / Expo project on Windows
2. Install @rive-app/react-native
3. Run npx expo run:android or ./gradlew assembleDebug

Root cause

CMakeLists.txt references source files in nitrogen/generated/ using absolute paths
(e.g. C:/Users/.../node_modules/@rive-app/react-native/nitrogen/generated/SomeFile.cpp).

When CMake maps an absolute Windows path to an object file output path, it replaces
the drive letter colon (C:) with C_, producing:

CMakeFiles/rive.dir/C_/Users/.../nitrogen/generated/SomeFile.cpp.o

Ninja then calls mkdir on this path to create the output directory.
On Windows, Ninja's mkdir does not create intermediate directories
(unlike mkdir -p on Unix). Since C_/ doesn't exist inside the CMake
build directory, mkdir fails with No such file or directory.

[mfazekas]

Could not reproduce on windows 11 with this exact configuration:

• Windows 11 Pro (build 26200), LongPathsEnabled=0
• JDK 17, Node, Expo SDK 55 (RN 0.83.6), @rive-app/react-native tried at both
  0.4.6 and 0.4.7, react-native-nitro-modules 0.35.6
• Android SDK: Platforms;android-35, build-tools; 35.0.0, ndk;27.1.12297006, cmake; 3.22.1 (ships ninja 1.10.2)
• Built ./gradlew assembleDebug -PreactNativeArchitectures=arm64-v8a from both a short path (C: \Users\boga\rive-repro) and a deeper junction path that produced object file paths up to 310 chars (well over MAX_PATH).
  All three runs BUILD SUCCESSFUL. The CMakeFiles/rive.dir/C_/Users/... object paths described in the issue are generated by CMake here, but ninja 1.10.2 in our setup creates the intermediates without error.

Could you share, to narrow it down:

1. Output of <ANDROID_HOME>\cmake\3.22.1\bin\ninja.exe --version (in case AGP picked up a different CMake/ninja)
2. Exact Expo SDK version - the report says SDK 53 but RN 0.83.6 ships with SDK 55; one of those is off
3. NDK version (<ANDROID_HOME> \ndk\ directories)
4. Full project path on disk, and whether it's under a OneDrive-redirected folder (C: \Users<name>\OneDrive..)
5. Output of reg query "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled
6. Whether you have a non-SDK CMake on PATH (where cmake)
7. The full ninja error including the bytes between Users/ and node_modules/ - the snippet Users//...//node_modules looks redacted; the unredacted middle is what would point to the real failure
   Note: installing cmake;3.31.6 (ships ninja 1.12.1 with explicit long-path support) via SDK Manager and pinning it could sidestep this either way: android { externalNativeBuild { cmake { version "3.31.6" } } }

[atuldedha]

1. ninja.exe --version

1.10.2

2. Exact Expo SDK version

Correction: it was Expo SDK 55 (not 53 — typo in the original report).

3. NDK version

NDK installed: 27.1.12297006.

4. Full project path + OneDrive

Original path was C:\Users\Lenovo\react-native-projects\react-native-learn — not under OneDrive. Moving to C:\rnl made the error disappear completely. That's what points to path length as the cause. (able to build the app after moving here)

5. LongPathsEnabled

LongPathsEnabled = 0x1 (enabled). So the failure happened despite long paths being enabled in Windows — which suggests Ninja's mkdir doesn't honor the Win32 long-path API.

6. Non-SDK CMake on PATH

No CMake on PATH at all (where cmake returns nothing). AGP used the SDK-bundled one at C:\Users\Lenovo\AppData\Local\Android\Sdk\cmake\3.22.1.

** NOTE: I was able to resolve the build error by moving my project to a shorter project folder