What's the Recommended CLI Environment Variable Path after VS Code Integration?

[Suess]

Hi,

After updating to the latest VS Code extension pack v3.8, what is the recommended path for executing CMake commands from command line? I uninstalled the STM32CubeCLT since it's now bundled, perhaps this the wrong choice?

I want to test running commands to upgrade our CI/CD pipelines to be up-to-date.  Also found following path which contains `cube.exe` as a CLI wrapper. My concern is setting an environment variable to a path with a version number (`/...-core-1.2.0-.../`) that ends up being a moving target.

> `C:\Users\USERNAME\.vscode\extensions\stmicroelectronics.stm32cube-ide-core-1.2.0-win32-x64\resources\binaries\win32\x86_64`

Any assistance would be greatly appreciated.

[Suess · Accepted solution]

After further research, it appears that you can use both options:

1. STM32 VS Code only - Command line possible via VS Code's [Terminal > "File Compilation"] which launches automatically with project and sets the PATH.
2. STM32 VS Code + STM32CubeCLT - Manually setting CLT in the PATH environment variable. 

Outcomes:

• Option 1
  • PRO: Appears to use less hard drive space
  • CON: Global PATH environment variable changes during each upgrade.
  • CON: Terminal > "File Compilation" doesn't always appear.. leaving you to search for the extension path.
• Option 2
  • You'll have duplicated copies of build tools
  • PRO: Can execute commands from any terminal. Good for testing CI/CD commands ahead of time.
  • CON: Uses an additional ~1.7 GB of space.

[Cartu38 OpenDev]

@Suess
I would no shoot for CLT myself because is going to be deprecated see https://community.st.com/t5/stm32cubeide-for-visual-studio/support-sharing-toolchains-between-stm32cube-for-vs-code-and/td-p/834619

I would recommend to rely on brand new STM32Cube bundles instead. You can set them all based on integrated bundle manager of Thanks couple of CLI calls.

To start based on a VS Code integrated terminal have a try to get `cube`:

cube bundle install cube-wrapper

You're going to get cube out of any VS Code context. Just use it out of VS Code pointing to.

You can too get '.bundle' files which are basically zip files and possibly you get all of them per platform (for CI/CD):

cube bundle download  cube-wrapper --platform x86_64-linux

cube bundle download  cmake --platform x86_64-linux
cube bundle download  ninja --platform x86_64-linux 
cube bundle download  gnu-tools-for-stm32@14.3.1+st.2 --platform x86_64-linux

cube bundle install cmake-4.2.3+st.1-x86_64-linux.bundle
....

Ends with on request atomic setup so saving hard disk space, flexibility about versions management,  .... let's say all good :)

[Suess]

Thank you, @Cartu38 OpenDev for the added information and reference link for myself and future readers!

When they spoke of stop CubeCLT, I'm assuming he was referring to the use case of the build tools and VS Code, and not CubeCLT as a whole. Overall, people will still need the ability to perform CI/CD on their build servers, which that tool (though bloated) comes handy.

I really like that they're moving forward with the Bundles for smaller install sizes / no duplicated tooling. That's a win!

Thanks again!

[Cartu38 OpenDev]

@Suess 
In real CLT and bundles contents are the very same. CLT can be stopped in real for now ... bundles are enabling the very same but more flexible, more atomic more, ... I consider like you it's a win !