Skip to main content
X
xiaofeizai
Visitor II
August 28, 2025
Solved

Support sharing toolchains between STM32Cube for VS Code and STM32CubeCLT

  • August 28, 2025
  • 2 replies
  • 591 views

Currently, STM32Cube for Visual Studio Code introduces a new bundled package manager which replaces STM32CubeCLT.
However, when developing STM32 projects with other IDEs (e.g. CLion), STM32CubeCLT is still required to provide the build environment.

This leads to several problems when using multiple IDEs (VS Code + CLion):

  • Separate installations of toolchains (STM32Cube for VS Code and STM32CubeCLT) consume extra disk space.

  • STM32CubeCLT cannot be updated incrementally; users must download the whole package.

  • STM32Cube for VS Code currently cannot manage STM32CubeCLT packages, leading to duplicated toolchain management.

  • By default, tools are installed on C:\ drive, which is inconvenient for users with limited system disk space.

Feature request:

  • Allow STM32Cube for VS Code’s package manager to use and manage STM32CubeCLT packages.

Benefits:

  • Reduce disk usage by avoiding duplicated toolchains.

  • Simplify updates and package management.

  • Improve developer experience when using multiple IDEs (VS Code + CLion, etc.).

 

      This topic has been closed for replies.
      Best answer by mattias norlander

      Hi @xiaofeizai ,

       

      Thanks for starting this thread. I 100% agree with the headaches you describe, you summarize them well. I can probably list a few more both end-user and ST internal. But I will refrain from going into rant mode. :)

       

      Clearly we need to make a transition!

       

      The plan is to stop CubeCLT.

      • It is a monolithic package including too much stuff, and the average user only need a few components from this package.
      • And we update it maximum 3x per year. Means fixes to svd-files etc is shelfed internally. All-in-all a solution which does not scale.

       

      The plan is to introduce the bundle manager as its own stand-alone project.

      • It will become an entry point both for STM32 developers and IDE partners like JetBrains CLion.
      • It allows end-users to obtain and update individual tools to get bug fixes and new STM32 target support with minimal (low risk) updates and preserve precious disk space.
      • Meanwhile it allow ST various internal tool teams to push updates without "corporate release synchronization hell".

       

      Everybody wins, but we are not 100% there yet in terms of making the the cube bundle manager into a "stand-alone product". And until we have cube bundle manager as a product we cannot fully stop STM32CubeCLT.

       

      FYI, I am in contact with JetBrains development team and we are educating them on the bundle manager to help them move away from CubeCLT towards cube bundle manager.

       

      Feel free to ask, and I encourage other people on the forum to jump in and share your feedback both on this direction and issues/requests you may have on this topic for the future! :)

       

      /Mattias

      2 replies

      M
      mattias norlanderAnswer
      ST Employee
      August 29, 2025

      Hi @xiaofeizai ,

       

      Thanks for starting this thread. I 100% agree with the headaches you describe, you summarize them well. I can probably list a few more both end-user and ST internal. But I will refrain from going into rant mode. :)

       

      Clearly we need to make a transition!

       

      The plan is to stop CubeCLT.

      • It is a monolithic package including too much stuff, and the average user only need a few components from this package.
      • And we update it maximum 3x per year. Means fixes to svd-files etc is shelfed internally. All-in-all a solution which does not scale.

       

      The plan is to introduce the bundle manager as its own stand-alone project.

      • It will become an entry point both for STM32 developers and IDE partners like JetBrains CLion.
      • It allows end-users to obtain and update individual tools to get bug fixes and new STM32 target support with minimal (low risk) updates and preserve precious disk space.
      • Meanwhile it allow ST various internal tool teams to push updates without "corporate release synchronization hell".

       

      Everybody wins, but we are not 100% there yet in terms of making the the cube bundle manager into a "stand-alone product". And until we have cube bundle manager as a product we cannot fully stop STM32CubeCLT.

       

      FYI, I am in contact with JetBrains development team and we are educating them on the bundle manager to help them move away from CubeCLT towards cube bundle manager.

       

      Feel free to ask, and I encourage other people on the forum to jump in and share your feedback both on this direction and issues/requests you may have on this topic for the future! :)

       

      /Mattias

        X
        xiaofeizaiAuthor
        Visitor II
        August 29, 2025

        Hi mattias norlander,

        Thanks a lot for your reply.
        I really agree with the decision to move away from CubeCLT towards the Cube bundle manager — that’s definitely the right direction.
        Also, I really appreciate your active collaboration with the JetBrains team to make the STM32 development ecosystem better. It will make things much faster and easier for developers.
        I’m excited to see the Cube bundle manager become a stand-alone product in the future!

          T
          Tom_pm
          Graduate II
          November 18, 2025


          Does ST have update on the bundle manager @mattias norlander ?
          - When can we expect the first stand alone release?
          - How long can be expect CubeCLT releases along the side of new CubeIDE releases?

           

          Best Thomas

           

          PS: I soon need to setup a build-test-release pipeline, and would like avoid doing the toolchain stuff twice.

          Terms & ConditionsAccessibility statement