FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Support sharing toolchains between STM32Cube for VS Code and STM32CubeCLT

Go to solution
xiaofeizai
Associate

‎2025-08-28 5:57 AM

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.).

 

Labels:
1 ACCEPTED SOLUTION

Accepted Solutions
Go to solution
mattias norlander
ST Employee

‎2025-08-29 12:22 AM

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

View solution in original post

2 REPLIES 2
Go to solution
mattias norlander
ST Employee

‎2025-08-29 12:22 AM

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

Go to solution
xiaofeizai
Associate
In response to mattias norlander

‎2025-08-29 12:40 AM

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!

Top