• State Verified Answer
  • Replies 2 replies
  • Subscribers 68 subscribers
  • Views 109 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 335033
Options

NCS_TOOLCHAIN_VERSION default

Burt

In ticket Case ID 290251, Torsten Rasmussen provides the following advice to ensure that the toolchain corresponding to the SDK is used to build the SDK (this applies to nrfutil and nRF Connect for Desktop's Toolchain Manager)

To avoid typing this for each build in this workspace, you can set this permanently for the workspace using `west config` like this:

west config --local build.cmake-args -- -DNCS_TOOLCHAIN_VERSION=2.0.0

(The advice was provided for working with v2.0.0 SDK of course.)

My question is why is this not set up for us in <SDK TREETOP>/.west/config when we download a version of the SDK.
The current situation is thatunless you use VS Code you build with a somewhat random toolchain (or even pair of toolchains)
unless you have done an enormous amount of research to know that NCS_TOOLCHAIN_VERSION needs to be set (either to NONE or the SDK version you are building in).
The chances of having the build system try to pull the python executable and the rest of

python from two different toolchains and then failing is pretty large for most users that are not familiar with the NCS_TOOLCHAIN_VERSION define.

Thanks,

Burt Silverman

Parents
  • +1

    Hello,

    I apologize for the delayed reply; I somehow missed this ticket in my queue.

     Regarding the issue you mentioned, I understand the frustration of working with SDKs and build environments that require specific toolchains. For continous integration and continuous deployment environments, explicitly setting the toolchain version ensures that every build uses the same tools, which helps avoid inconsistencies that could occur if different versions are used by mistake. This is likely one of the reasons why it’s not automated. Additionally, for VS Code extensions, developers typically don’t need to worry about setting the NCS_TOOLCHAIN_VERSION.

    However, if you’re still concerned about this issue, I can check with our developers internally. Just let me know, and I’ll raise this matter internally.

    Regards,

    Priyanka

Reply
  • +1

    Hello,

    I apologize for the delayed reply; I somehow missed this ticket in my queue.

     Regarding the issue you mentioned, I understand the frustration of working with SDKs and build environments that require specific toolchains. For continous integration and continuous deployment environments, explicitly setting the toolchain version ensures that every build uses the same tools, which helps avoid inconsistencies that could occur if different versions are used by mistake. This is likely one of the reasons why it’s not automated. Additionally, for VS Code extensions, developers typically don’t need to worry about setting the NCS_TOOLCHAIN_VERSION.

    However, if you’re still concerned about this issue, I can check with our developers internally. Just let me know, and I’ll raise this matter internally.

    Regards,

    Priyanka

Children
  • 0 in reply to Priyanka

    Thanks, Priyanka, I can live with the current arrangement. I found that usually I can set the default toolchain in nrfutil to the most recent one I have downloaded, and that works for building older levels of SDK, at least in the cases that I have tried.

    Be ready for a new ticket I may open for this finding: I have found that in Linux, "nrfutil toolchain-manager launch --shell" is starting a process that uses almost 20% of the CPU according to the top utility.

    Burt

Related