A small rant about the STM32 VS Code extension

[totoro]

As an embedded developer, I already have CMake, Ninja, and the GNU Arm Embedded Toolchain installed and properly configured in my system PATH. These are standard development tools that many of us manage ourselves.

What frustrates me is that the STM32 VS Code extension seems to completely ignore the existing environment and immediately downloads its own copies of CMake, Ninja, and arm-none-eabi-gcc.

Why?

Why not first check whether compatible versions already exist on the system? If they do, use them. If they don't, then offer to download them. That seems like a much more reasonable approach.

The current behavior feels like this:

• Ignore the system environment

• Ignore tools already installed by the user

• Download another copy of everything anyway

The result is duplicated toolchains, wasted disk space, and less control over the development environment.

I understand that bundling dependencies may simplify onboarding for beginners, but experienced developers should have the option to use their own toolchain. A simple setting such as "Prefer system-installed tools" would solve the problem.

VS Code extensions are not package managers, and they certainly shouldn't assume that every user needs another copy of CMake, Ninja, and GCC downloaded into a hidden directory.

For developers who care about maintaining a clean and controlled build environment, this design choice is genuinely frustrating.

[mattias norlander]

Hi totoro,

 

Thanks for these feedbacks! It's a fair criticism. It is sometimes hard to support both the beginners and the expert users. Trade-offs need to be made. Unfortunately, in this case, you belong to the latter category os users.

 

For CMake and Ninja, you're correct: those are interchangeable standard tools, and downloading a second copy when a compatible one is already on your PATH is wasted disk and bandwidth.
  
The one nuance is the compiler. Our GNU Tools for STM32 (GCC) isn't a drop-in equal of the stock GNU Arm build — it's slightly modified to support some IDE features such as stack analysis and cyclomatic complexity, we build libraries with different optimization level, and we have added long path support (latest patch list here: https://github.com/STMicroelectronics/gnu-tools-for-stm32/blob/14.3.rel1.20251027-0700/README.md). We have already been able to up-stream most of our patches, but all are not accepted up-stream, hence we are still stuck our own own flavour of GCC. Our GCC also have long path support on Windows. Before our GCC had long path support our user base (with 85% windows users) reported weekly/daily issues where they struggled to build example projects coming from ST since the packaging and installation location lead to paths >250 characters. the example project packaging lead to bad first-time experience for people using our IDE. And our support team had to fight against this issue a lot...

I don’t think that matters to your user type. But we must sometimes make “design choices” in our tools. We try to always aim for both beginner-friendliness and flexibility. Our first prioritiy is in this case beginner-friendliness! This is not always true...

 

STM32CubeIDE for VS Code is also not just directly calling cmake/ninja/gcc. All calls are passed through the “cube” CLI wrapper… The CLI wrapper reads the project lock files. The lock files pin exact CLI tools versions for each project so a build is reproducible across machines — your laptop, a teammate's, and the CI runner all resolve to the same binaries, and the same bundle drops straight into a pipeline.
Our tool sourcing model is “project-driven”: the project declares the toolchain it needs, rather than depending on whatever happens to be installed on the system. This is done both for re-producibility reasons but also to allow big companies to efficiently roll out tools across large teams. Check-out the tools with your projects. You pay in terms of wasted disk space. But larger teams gain in terms of tool deployment speed and the re-producibility promise. If your tool environment breaks the project lock-files and the bundle manager allow you to restore it.

As mentioned, these are deliberate choices we have made, with consequences for some users. Sorry about that! Serving a mass-market audience is challenging. Always trade-offs.

 

The way I see it you have three choices:

 

• Option1: Use CMake Tools from Microsoft and cortex-debug extension instead of our stuff.

 

• Option2: Use our extension as they are and trade disk space for re-producibility.

 

• Option3: Create empty metadata bundles pointing at your own already installed CMake, Ninja and GCC version. The bundle system supports linking to tools outside the bundle itself (the tools you already have installed). But there are no guarantees that all features in our VS Code extension will work with your GCC. In the end our VS Code environment might (nobody have tested your use case) still download cmake/ninja and gcc when creating/importing new projects. But you would probably be able to clean that out once you have your project setup to rely on your own tools via your own custom bundles. This approach is completely experimental.

 

 

If Option3 did not scare you away, you will need to explore it on your own and learn the basics of bundle creations. Inside VS Code terminal run the command (cube command is probably not on your system PATH):

    cube bundle init

Then open the CubeBundle.json template file that is generated and have a look at “commands” {“name”: “your-gcc”, “exec”: “???”}

I do not expect you to pursuit the option3. I hope you instead see the rationale behind option2 and conclude that the benefits outweigh the negatives…  Let’s be honest: your request is not a supported use case today. And I don’t think we can support this any time soon on the roadmap. But both me and some other colleagues (who pointed out this thread to me) enjoyed reading your feedback!

 

Kind regards, Mattias