NCS 2.8.0: path length problem during build under Windows

[rgrr2]

Hello,

I know that this issue comes up from time to time.  I'm raising it again, because to my opinion there have to be a solution for this.  Perhaps there is, that's the other reason I'm asking...

Since upgrade from NCS 2.7.0 to 2.8.0 we are facing the problem with path names exceeding some toolchain limit under Windows (Windows is already setup to use long names).

During build, the compiler complains that it cannot open a dependency file:

C:/u/src/BlueConnect_NordicApplication-Zephyr/submodules/BlueConnect_Core/ApplServ/RePAc/FieldDevice/Connector/CDeviceRemoteParamAccessConnectorBase.cpp:267:1: fatal error: opening dependency file submodules\BlueConnect_Core\build-config\Zephyr\CMakeFiles\blueconnect-core.dir\__\__\ApplServ\RePAc\FieldDevice\Connector\CDeviceRemoteParamAccessConnectorBase.cpp.obj.d: No such file or directory

The file actually resides in "C:\u\src\BlueConnect_NordicApplication-Zephyr\submodules\BlueConnect_Core\ApplServ\RePAc\FieldDevice\Connector\CDeviceRemoteParamAccessConnectorBase.cpp". These are 152 characters, actually not too much.

But the build system adds "some" extra information and creates a path "C:\u\src\BlueConnect_NordicApplication-Zephyr\_build\BlueConnect_NordicApplication-Zephyr\submodules\BlueConnect_Core\build-config\Zephyr\CMakeFiles\blueconnect-core.dir\__\__\ApplServ\RePAc\FieldDevice\ConnectorX\CDeviceRemoteParamAccessConnectorBase.cpp.obj.d" which has 261 characters, which exceeds some magic toolchain (and Windows) limit.

I guess that cmake actually is capable of avoiding those limits by exchanging parts of a long path with some hash.  I can observe those hashes somewhere in the build directory structure, but the directories below are empty (I guess that the build process crashed before filling them).

So I'm looking desperately for a solution of this issue.

And no: restructuring everything is not an option, because this is an existing code base.  One will run into this problem sooner or later due to different project root directories ("hey user, don't forget to unpack the repository into your drive root!").  And if one is unlucky, then the CI pipelines will give the rest to the efforts taken to make the paths shorter.

Thanks for response & regards

Hardy

[JONATHAN LL]

I am currently not aware of a solution that does not include renaming or restructuring stuff if you want to build in tree. What you can try to do is build the project out of tree and that should help with this issue as long as you put the project somewhere with few characters I belive. 

Regards,
Jonathan

[rgrr2]

Thanks, sounds at least as an intermediate solution.  Could you please tell how to move the build project out of the tree.

[JONATHAN LL]

Copying the sample out to a folder paths that is shorter such as C:/NCS/Out-OF-Tree-builds/  is how, so it does not always need to build in tree and build with the working dir being the workspace.

You can use a shorter name like C:/project/ or whatever here but this works. 

I copied the central_uart sample to a folder I named out of tree and ran the build from VS code nRF extension there. 

so the following:

C:\WINDOWS\system32\cmd.exe /d /s /c "west build --build-dir c:/Out-Of_Tree/central_uart/build c:/Out-Of_Tree/central_uart --pristine --board nrf52840dk/nrf52840 -- -DNCS_TOOLCHAIN_VERSION=NONE -DBOARD_ROOT=c:/out-of_tree/central_uart"

Regards,
Jonathan