Issues with Long Pathnames

[ReinhardKeil]

There are still issues with long pathnames that we should address. This issues result in CMake errors such as:
**The maximum full path to an object file is 250 characters (see CMAKE_OBJECT_PATH_MAX)

Potential solutions:

For users:

• document how to extend the PATH limit to 1024 characters (may require changes to some Windows registry settings) and set CMAKE_OBJECT_PATH_MAX to this value. See also: https://knowledge.autodesk.com/support/autocad/learn-explore/caas/sfdcarticles/sfdcarticles/The-Windows-10-default-path-length-limitation-MAX-PATH-is-256-characters.html

• document guidelines that explain that path length limits may apply when long filenames are chosen.

in CMSIS-Toolbox 2.0

• Try to reduce the path components in the tmp directory, i.e. instead of:

  C:\w\AWS_MQTT_MutualAuth_SW_Framework\tmp\Demo\WiFi\Release\CMakeFiles\Demo.Release+WiFi.dir\....
  

  Just:

  C:\w\AWS_MQTT_MutualAuth_SW_Framework\tmp\Demo\WiFi\Release\CMakeFiles\dir\....
  

• Use relative paths in build script, i.e. instead of:

  set(PRJ_DIR "C:/w/AWS_MQTT_MutualAuth_SW_Framework")
  set(OUT_DIR "C:/w/AWS_MQTT_MutualAuth_SW_Framework/out/Demo/WiFi/Release")
  set(INT_DIR "C:/w/AWS_MQTT_MutualAuth_SW_Framework/tmp/Demo/WiFi/Release")
  

  Just:

  set(PRJ_DIR ".")
  set(OUT_DIR "./out/Demo/WiFi/Release")
  set(INT_DIR "./tmp/Demo/WiFi/Release")
  

[brondani]

It seems enabling the long path in Windows is not sufficient for some tools.
For example armlink complains about a missing object file:

Fatal error: L6002U: Could not open file CMakeFiles/fxls8974cf_motion_wakeup.debug+frdmk22f_a8974.dir/a6d0b102fc087752ef65621176909b6b/fsl_component_generic_list.o: No such file or directory

Even if the file is there:

$ less CMakeFiles/fxls8974cf_motion_wakeup.debug+frdmk22f_a8974.dir/a6d0b102fc087752ef65621176909b6b/fsl_component_generic_list.o
"CMakeFiles/fxls8974cf_motion_wakeup.debug+frdmk22f_a8974.dir/a6d0b102fc087752ef65621176909b6b/fsl_component_generic_list.o" may be a binary file.

For the time being to cope with such limitation paths leading to object files should be kept as short as possible, for example by customizing intdir or by using the csolution --output option.

The "use of relative paths in build script" doesn't help, CMake always generates full path for object files, independently of source paths being relative. From CMAKE_OBJECT_PATH_MAX:
CMake computes for every source file an object file name that is unique to the source file and deterministic with respect to the full path to the source file. This allows multiple source files in a target to share the same name if they lie in different directories without rebuilding when one is added or removed.

[tarek-bochkati]

well, I'm jumping here to highlight that a fix from ninja side is merged upstream.
internally we switched to latest ninja master branch, and it resolved our issues with long path.
please refer to: ninja-build/ninja#2225

any way, optimizing the generated paths into the generated cmakelists is more than welcome.

[jkrech]

@tarek-bochkati looks like no official release of ninja was made since this change got merged.

[ReinhardKeil]

I'm trying to address this with documentation, but run into issues.

My attempt:

• create directory with name: "C:\w\A1234567890B123456789C0123456789D0123456789E0123456789F0123456789G0123456789H01234567890IH01234567890JH01234567890"
• Checkout to this directory: https://github.com/RobertRostohar/NXP_Sensor_SDK
• Enable long pathname support as documented here https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
• Add to AC6.6.19.0.cmake: set(CMAKE_OBJECT_PATH_MAX "1024")
• Run with VS Code extensions: examples\issdk\sensors\fxas21002\fxas21002 - Target: frdmk22f_agmp03 - Build: debug - Project: fxas21002_fifo

This ends with a ninja error at this command:

cbuild c:\w\A1234567890B123456789C0123456789D0123456789E0123456789F0123456789G0123456789H01234567890IH01234567890JH01234567890\NXP_Sensor_SDK\examples\issdk\sensors\fxas21002\poll_spi\fxas21002_poll_spi.debug+frdmk22f_agmp03.cprj

@tarek-bochkati @jkrech is there a way to get a version of ninja with the fix that is described above?

[jkrech]

@ReinhardKeil The last official release is still from Aug. 2022 so you would need to create a build from master branch.

[ReinhardKeil]

can confirm that new ninja version would solve the build issue. Remaining issues are described here #838

[brondani]

See #838.