Skip to main content
This topic has been closed for replies.

1 reply

M
mattias norlander
ST Employee
April 1, 2025

Hi,

Thanks for sharing this need. Could you elaborate a bit more on "why" you want to use the system-wide tools?
Honestly, this is not really the direction we are moving towards. We are more moving towards a direction where each of your projects can use a unique set of CLI tools sourced via a "bundle manager". The purpose of this bundle manager is to:

  • Allow you to use a unique set of CLI-tools for each of your concurrently developed/maintained STM32 dev projects (opposed to a system-wide set of tools for all your projects --> better flexibility/control).
  • To allow you to "commit" not only your code, but the project will also contain a "tool manifest" describing the tools the project depends on. When your colleagues check-out your project they get both the code and the tools! This guarantees the same behavior across dev and ACI machines. This is hard to achieve if you rely on system-wide tool paths...
  • And to guarantee that 10 years later, when someone else has to make a bug fix on the code base you started, checking out the project gives this person both the code and also the identical tool environment (re-producibility again...)

 

... We believe that the majority of users are going to find this type of "tool deployment" workflows to be very efficient. But the price you pay for it is that we have to manage the PATHs seen by VS Code with a "wrapper".

Let me know why you want to use system-wide tools, so that we can understand how to address those needs. Maybe the proposal above even solves your issues?

    I
    ianzoneAuthor
    Explorer II
    April 1, 2025

    Thanks for your reply.

    I understand the benefits of using isolated dependencies for each project, but I'm developing STM32 only as a hobby and for study, and it's not worth it for me to download 2GB more for the tools I already have (Cmake, ninja, Arm GNU Toolchain, and CubeProg).

    Also, not happy with the download experience. I have to log in to download every time, and the network from my place is very slow. 

    For compatibility, I think it is better to let cubemx put toolchain versions into the cmake file so users would know when to download the specific version. 

    M
    mattias norlander
    ST Employee
    April 2, 2025

    In the new solution the download is not via st.com, and thereby no log-in required. One issue crossed off the list... 

    But your concern about additional disk space usage is real. Myself I am partly Mac user, disc space comes at a hefty price. I think that at least any Mac user would share your concern...

     

    @ianzone wrote:

    For compatibility, I think it is better to let cubemx put toolchain versions into the cmake file so users would know when to download the specific version. 

    The challenge for us is that we have to provide tooling for HW engineers and for SW developers. And things must work out-of-the-box. I believe in the new solution, but we need also to enable guys like you, who need more flexibility. I think we can solve that in a coming update!

      Terms & ConditionsAccessibility statement