• State Verified Answer
  • Replies 1 reply
  • Subscribers 69 subscribers
  • Views 104 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 339322
Options

Build issue in version 2.9.0

CktDesigner

Jonathon LL requested that this be posted as a separate issue:  (See Case ID: 336683)

I'm having a problem trying to migrate from 2.7.0 to 2.9.0.

My projects are not "in-tree" (I have a custom board and my project directory is separate from where toolchains and SDKs are stored.).

When creating a build configuration, one is asked to provide a name for the build.   This is used to create a directory/folder where all build info is created/stored.    In previous releases, this build folder is created and all make scripts, object files, etc. are stored there.   For 2.9.0, it looks like the build folder is created, but then another folder is created in the build folder using the project name.   This folder, with the project name, is where the make scripts, object files, etc. are stored.  In my case, the project name is pretty long and the extra characters (due to the extra level of file hierarchy) pushes file names over the Windows limit.

So, for example, if the project name is "NewProj" and the build configuration name is "NewBuild", a directory named "NewBuild" is created in the project directory (NewProj).  Some directories (modules, zephyr, etc.) are created in this "NewBuild" directory, but there is also a new directory there named "NewProj",    This (lower in the hierarchy) folder contains new versions of all of the folders and this is where most files then appear.   So most files then appear at:   .../NewProj/NewBuild/NewProj/(build files)

Since my project name is long, appears twice in the ultimate path, and its position in the file system is not near "/" the full path name for most files is very long and exceeds the max length in WIndows. 

I'm wondering if this extra level was introduced as a "feature" or a bug.   Why the extra level??

Parents
  • +1

    Hello,

    First of all, sorry for the late reply.

    And secondly, I have noticed that change too. What happened is that we changed parts of the building system to what is native to Zephyr, called Sysbuild. With this change comes longer paths in the build folder. We have notified our developers, and they are looking into it. Unfortunately, most of them are not on Windows, like you and me, and hence, they don't see the struggle directly. 

    So in the meantime, until we sort this out, I can give you the best practice that I have found to be working.

    You should try to keep the path to your projects short. It doesn't necessarily mean that you need to put your entire SDK in the same location as the applications that you are working on. But the applications where the build folders are generated should be placed not too far from C:\. I use:

    C:\nordic\ncs\my_apps\2.9.0\<descriptional folder>\NewProj, which would then contain NewBuild. <descriptional folder> is just a way to group together some applications, so that they are easy to find, and a bit more tidier than having everything in the same folder. Some examples are "bluetooth", "mesh", "basic", etc.

    Whenever I want to test a new sample, let us say peripheral_uart, I copy it from v2.9.0\samples\bluetooth\peripheral_uart, and paste it where I keep my samples. Then I add it to VS code using "open an existing application", or build from command line. 

    But even following this, I have seen samples that I needed to put all the way down to C:\test\ to be able to build. I move it there, and move it back when I am done. 

    So while it is not ideal, there is not much I can do to help you further at the moment, unfortunately. You can choose to stick with 2.9.0, and make sure to tick off "No Sysbuild" at the bottom when you create your build configuration. If you build using the command line, you can add: --no-sysbuild to your build command, and it should use the "old" way to build. Unfortunately, I don't think that will stick around for much longer, so if you want any new features, you need to make the path to your applications shorter.

    I sure will add this ticket to my list of tickets that have reported this issue, so hopefully we can solve this sooner rather than later.

    Thank you for reaching out!

    Best regards,

    Edvin

Reply
  • +1

    Hello,

    First of all, sorry for the late reply.

    And secondly, I have noticed that change too. What happened is that we changed parts of the building system to what is native to Zephyr, called Sysbuild. With this change comes longer paths in the build folder. We have notified our developers, and they are looking into it. Unfortunately, most of them are not on Windows, like you and me, and hence, they don't see the struggle directly. 

    So in the meantime, until we sort this out, I can give you the best practice that I have found to be working.

    You should try to keep the path to your projects short. It doesn't necessarily mean that you need to put your entire SDK in the same location as the applications that you are working on. But the applications where the build folders are generated should be placed not too far from C:\. I use:

    C:\nordic\ncs\my_apps\2.9.0\<descriptional folder>\NewProj, which would then contain NewBuild. <descriptional folder> is just a way to group together some applications, so that they are easy to find, and a bit more tidier than having everything in the same folder. Some examples are "bluetooth", "mesh", "basic", etc.

    Whenever I want to test a new sample, let us say peripheral_uart, I copy it from v2.9.0\samples\bluetooth\peripheral_uart, and paste it where I keep my samples. Then I add it to VS code using "open an existing application", or build from command line. 

    But even following this, I have seen samples that I needed to put all the way down to C:\test\ to be able to build. I move it there, and move it back when I am done. 

    So while it is not ideal, there is not much I can do to help you further at the moment, unfortunately. You can choose to stick with 2.9.0, and make sure to tick off "No Sysbuild" at the bottom when you create your build configuration. If you build using the command line, you can add: --no-sysbuild to your build command, and it should use the "old" way to build. Unfortunately, I don't think that will stick around for much longer, so if you want any new features, you need to make the path to your applications shorter.

    I sure will add this ticket to my list of tickets that have reported this issue, so hopefully we can solve this sooner rather than later.

    Thank you for reaching out!

    Best regards,

    Edvin

Children
No Data
Related
Terms of service