nRF Connect SDK v3.4.0 - Windows 11 - Fails to compile builds with error CMAKE_BINARY_DIR length (109) exceeds 90 characters

[zpm1066]

Hello,

Under Windows 11 Pro, nRF Connect SDK v3.4.0 fails to compile builds with error "CMAKE_BINARY_DIR length (109) exceeds 90 characters."

The same build on Windows 11 Pro & NCS v3.3.3 (and previous releases) builds successfully. Also, the same source builds successfully under macOS Sequoia.

I'm not sure why the errors occurs, as Windows 11 MAX_PATH  length is 260 characters.

Appreciate if someone in Support can assist. Thank you.

Kind Regards.

[Natasha_C]

Hi Ravi,

We're looking into your request and will get back to you as soon as possible.

Appreciate your patience!

[zpm1066]

Hi Natasha,

Thank you for picking up the issue.


Kind Regards,
Ravi

[zpm1066]

Hi Natasha,

Do you have any updates? Thanks.



Kind Regards,
Ravi

[zpm1066]

Hi Natasha,

It's been a while since I last got an update. Do you have any updates? Thanks.

[Amanda Hsieh]

Hi Ravi, 

I've escalated this to another team, and they are actively investigating it now. It will take a little time to get to the bottom of this, but I'll keep you posted as soon as there's progress.

Regards,
Amanda H.

[zpm1066]

Thank you Amanda.

[Torsten Rasmussen]

Hi Ravi,

As it says in the CMake warning, it warns because it doesn't know which tools may cionsume the file:
```
CMake Warning in .../CMakeLists.txt:
  The object file directory

    <path>

  has 183 characters.  The maximum full path to an object file is 250
  characters (see CMAKE_OBJECT_PATH_MAX).  Object file

     <path>/<file>.obj

  cannot be safely placed under this directory.  The build may not work
  correctly.
```

CMake itself can handle long paths, but CMake doesn't know about other tools used as part of the build process, and thus it doesn't know if those tools supports windows long path or not.

In nRF Connect SDK we use different tools as part of the build process, such as: gcc, binutils, ninja, python, nrfutil, etc.

That's the reason for the warning. Whether the actual build will succeed depends on the tools used with that long path.

In the past, gcc itself had issues with long paths in Windows, but that has been fixed in latest toolchain used by nRF Connect SDK, however some tools provided by GNU binutils, are still not supporting Windows long path (binutils provides tools like ld, objcopy, objdump, readeld,...).
I don't know exactly which of the tools from binutils that doesn't support long path.

You have already tried shortening your install path, but the final path for the build, and thus path used by all build tools, is a combination of location of build folder and the build path created by CMake / ninja.
For example: `<build>/<sample>/modules/hal_nordic/modules/hal_nordic/nrfx/CMakeFiles/nrfx.dir/<disk-path-dup>/modules/hal/nordic/nrfx/drivers/src/nrfx_clock.c.obj`

This longer build folder path is decided by CMake and unfortunately increases the risk of hitting the long path issue of build tools.

It can be controlled by setting the CMake variable CMAKE_INTERMEDIATE_DIR_STRATEGY, which will shorten the build path.
The downside of that flag is that object files will go from something like: `<build>/<sample>/modules/hal_nordic/modules/hal_nordic/nrfx/CMakeFiles/nrfx.dir/<disk-path-dup>/modules/hal/nordic/nrfx/drivers/src/nrfx_clock.c.obj` to something like `.o/c79fae25/fd649f31.obj`. 

To use the shorten path, you can specify `-DCMAKE_INTERMEDIATE_DIR_STRATEGY=SHORT`.
Note, this CMake feature requires CMake v4.2 or newer.

Best regards

Torsten