Fixing Path Length Problems in CMake When Creating Android React-Native Reanimated

Common Path Length Errors During CMake Builds in React Native

Developers working with React Native on Windows often encounter path length limitations when building Android projects. One recurring issue is related to the react-native-reanimated package and its CMake configuration, which can lead to failed builds.

This error is typically indicated by a message that states "mkdir: No such file or directory", hinting at the creation of certain directories exceeding the permissible path length on the Windows operating system. This can be especially frustrating when developers attempt to build their apps using CMake and the Ninja build system.

Despite attempts like relocating the project closer to the drive’s root or modifying build configurations, these path length problems may persist. Such measures might help in some cases but do not always provide a permanent fix.

If you’re encountering this issue while working with react-native-reanimated, understanding the cause and exploring alternative solutions is crucial. Let’s dive into the problem, potential solutions, and ways to avoid this complication in the future.

Detailed Explanation of the Solution Strategies

In addressing the path length issue while building the react-native-reanimated library on Android using CMake, we implemented multiple script-based solutions. The first approach involved relocating the project files closer to the root directory. By using a shell script with specific commands like cp -r to copy all project files and mkdir to create a target directory if it doesn't exist, we aimed to mitigate the error related to long paths. This helps reduce the risk of hitting Windows' default maximum path length of 260 characters, which is common in nested React Native projects.

Another key solution was to modify the CMakeLists file to utilize relative paths instead of absolute ones. This method effectively addresses the path length limitations by preventing the generation of long, nested directory paths during the CMake build process. By defining relative paths using the CMake set command and employing commands like add_library and target_include_directories, the build system is directed to use shorter, relative file paths, which reduces the chance of encountering the "No such file or directory" error.

Additionally, enabling long path support on Windows proved to be a crucial step in resolving this issue. A PowerShell script was designed to modify the Windows registry key using Set-ItemProperty. This command allows Windows to bypass the default path length limit of 260 characters by enabling the "LongPathsEnabled" option. The script ensures the registry key is properly set, and uses the Get-ItemProperty command to verify that the modification was successful. This solution is essential when other path reduction methods are insufficient to avoid directory creation errors.

Finally, the PowerShell script utilizes the Start-Process command with the -Verb runAs flag to execute the script with administrative privileges. This is necessary because modifying registry settings requires elevated permissions. By combining these techniques—moving project files, modifying CMake configurations, and enabling long path support—we created a comprehensive strategy to resolve the CMake build error related to path length. These solutions not only mitigate the current error but also provide a reusable framework for tackling similar issues in future projects.

# Step 1: Define source and target directories
source_dir="C:/Users/ricar/Documents/Github/StockItUp"
target_dir="C:/StockItUp"

# Step 2: Create target directory if it doesn't exist
if [ ! -d "$target_dir" ]; then
  mkdir "$target_dir"
fi

# Step 3: Copy project files to the target directory
cp -r "$source_dir/"* "$target_dir/"

# Step 4: Confirm completion
echo "Project files moved to $target_dir"

# Set relative paths to reduce absolute path length issues
cmake_minimum_required(VERSION 3.10)

project(reanimated_project)

# Define relative path for source files
set(SOURCE_DIR "src/main/cpp/reanimated")

# Add source files using the relative path
add_library(reanimated STATIC ${SOURCE_DIR}/Common.cpp)

# Specify target properties
target_include_directories(reanimated PRIVATE ${SOURCE_DIR})

# Step 1: Open PowerShell as Administrator
Start-Process powershell -Verb runAs

# Step 2: Set the registry key for long paths
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1

# Step 3: Confirm the setting
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled"

Addressing Path Length Limitations and Build Strategies

Another key aspect to consider in resolving the "mkdir: No such file or directory" error is understanding how CMake interacts with the Ninja build system. Ninja is commonly chosen for its speed and efficiency in compiling code, but its compatibility with path length limitations on Windows can be challenging. To work around this, developers need to carefully configure CMake and Ninja in ways that help avoid excessive path lengths. This involves customizing the build process to use relative paths and keeping the directory structures as simple as possible.

A solution often overlooked is adjusting the default build configurations used by CMake or Ninja to better suit Windows’ file system constraints. For instance, one can add specific flags or define alternative build directories that do not exceed the maximum path length. Additionally, developers can review their project's dependency structure to identify and shorten unnecessarily deep or complex paths. This approach ensures a smoother build experience while reducing the risk of path-related errors during compilation.

It’s also crucial to evaluate the integration of third-party libraries like react-native-reanimated. Since these libraries have their own internal directory structures, ensuring compatibility with Windows' path length limitations may require custom adjustments. By modifying library-specific CMake configurations or relocating node modules to shorter paths, developers can maintain a functional build environment that is free from critical path length issues.