[cmsis-toolbox] Windows: long pathname support

[ReinhardKeil]

For solving #671 the following issues are open:

• new ninja version should be included in ctools
• new arm linker is required to support long pathnames

Changes to build tools:

When [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem] "LongPathsEnabled"=dword:00000001

• add to .cmake file: set(CMAKE_OBJECT_PATH_MAX "1024")
• list config command should display this setting (see [cbuild, csolution, cbuildgen] Add commandline option to display "environment" #783)

[brondani]

I still face issues even with ninja 1.11.1 when running the reproducer described in #671 (comment):

CMake Error:
  Running
   'C:/ProgramData/chocolatey/bin/ninja.exe' '-C' 'C:/w/A1234567890B123456789C0123456789D0123456789E0123456789F0123456789G0123456789H01234567890IH01234567890JH01234567890/NXP_Sensor_SDK/examples/issdk/sensors/fxas21002/tmp/fxas21002_fifo/frdmk22f_agmp03/debug/CMakeFiles/CMakeScratch/TryCompile-1oopss' '-t' 'recompact'
  failed with:
ninja: error: loading 'build.ninja': The system cannot find the path specified.

Environment:

$ systeminfo
...
OS Name:                   Microsoft Windows 10 Enterprise
OS Version:                10.0.19045 N/A Build 19045

$ csolution list environment
...
Long pathname support=enabled

$ ninja --version
1.11.1

Indeed the related ninja-build GH issue has been reopened on March 4th:
ninja-build/ninja#1900
See also CMake issue:
https://gitlab.kitware.com/cmake/cmake/-/issues/22435

Anyway at the present date it seems the microsoft vcpkg registry provides only ninja 1.10.2

$ vcpkg version
vcpkg package management program version 2023-06-22-f19f3d9939100085fe2f7e41502d60b08e2083b6

$ vcpkg find artifact ninja
...
microsoft:tools/ninja-build/ninja 1.10.2  Ninja is a small build system with a focus on speed.

On a side note the CMake variable CMAKE_OBJECT_PATH_MAX impacts only the hashing mechanism for generating object files with shorter paths. Increasing it does not help to solve the issue, at best it just evidences native tools that don't cope with long paths.

Further info: the ninja issue appears even when using ninja 1.12.0.git built from sources.
Now it is more evident because it happens already in the CMake Compiler Detection phase, which was skipped in CMSIS-Build versions lower than 1.6.0.

[tarek-bochkati]

@brondani could you retry with the latest ninja master HEAD
for every commit merge in ninja github an action is launched to test & compile ninja
a binary artifcat is kept and could be downloaded, for example herein: https://github.com/ninja-build/ninja/actions/runs/5111036290

[brondani]

@tarek-bochkati Testing the binary artifact that you pointed with the above mentioned reproducer still leads to long path issue:

 Run Build Command(s): D:/tmp/ninja-win/ninja.exe -v cmTC_a3946
    ninja: error: Stat(C:/w/A1234567890B123456789C0123456789D0123456789E0123456789F0123456789G0123456789H01234567890IH01234567890JH01234567890/NXP_Sensor_SDK/examples/issdk/sensors/fxas21002/tmp/fxas21002_fifo/evkmimxrt1060_agmp03/debug/CMakeFiles/CMakeScratch/TryCompile-ws87g7/testCCompiler.c): Filename longer than 260 characters

[brondani]

The following PR, submitted to the ninja-build repository, addresses the Filename longer than 260 characters error:
ninja-build/ninja#2321

Binaries:
ninja-linux.zip
ninja-windows.zip

[brondani]

From our side this issue is concluded.
The PR submitted to ninja-build was approved and merged.
External requirements, namely the Arm Compiler 6.21 and the ninja release 1.12.0 (no due date) are out of scope of cmsis-toolbox 2.2.0.